Claude for PowerPoint is an official Anthropic add-in that lets a person edit a deck conversationally inside the PowerPoint app, on the Pro, Max, Team, and Enterprise plans. An agent-native deck API is the opposite shape: software calls it, nobody opens an editor, and it returns a branded, editable .pptx. Same goal, two different drivers.

I build heydecks, so the phrase "claude for powerpoint" shows up in my inbox a lot, usually carrying a wrong assumption. People expect one answer, and there are two. One path is a human cleaning up slides with Claude sitting in the PowerPoint sidebar. The other is a script or an agent that needs a finished deck back and never touches PowerPoint at all. They look like the same job from a distance; up close they need different tools. This post is about telling them apart and picking right.

#What is Claude for PowerPoint?

Claude for PowerPoint is an add-in from Anthropic that runs inside the PowerPoint app and edits the deck open in front of you. You install it from the Microsoft Marketplace (search "Claude by Anthropic"), open the sidebar, and talk to Claude while it reads and changes your slides. It needs a paid Claude plan, and it is not on the free tier.

What makes it more than a chat window stapled to PowerPoint is that it respects your file. It reads your slide masters, fonts, layouts, and colors, then builds native shapes, text boxes, and charts that match, so the output stays editable instead of landing as a flat picture. Highlight one slide and it works on just that slide; start from a blank deck and you can ask it to draft a full presentation from a plain-language description. Connect a Microsoft 365 account and it can pull numbers from an Excel workbook in the same session. Anthropic's own help docs flag a prompt-injection caveat, since the model reads content you did not write, which is worth reading before you point it at files from outside your team.

#When is the Claude for PowerPoint add-in the right tool?

Reach for the add-in when a person is in PowerPoint and the deck already exists. That is its home turf, and on that turf it is genuinely good. You have a board deck that needs tightening, a slide whose bullets should become a diagram, last quarter's template that needs this quarter's numbers; you are the one steering, and the add-in edits in place against the file you already trust.

The honest read on quality is mixed, and it is early. On the Microsoft Marketplace the add-in sits around 2.6 out of 5 across 69 ratings as I write this, and it is still labeled beta: complex custom layouts sometimes need a manual pass, and chat history does not carry between sessions. None of that disqualifies it. The practitioners getting the most out of it on r/powerpoint do the same thing every time: hand Claude a detailed treatment, ask for a text-only slide-by-slide storyboard first, review that, and only then let it build. Treated as a fast, opinionated editing partner for a human in the room, it earns its place. The constraint is structural, not a bug: it needs desktop PowerPoint, a paid plan, and a person at the keyboard.

#What is an agent-native deck API, and how is it different?

An agent-native deck API is a deck generator that software calls directly, with no app open and no human in the editor. You send it a prompt, some markdown, or a URL over HTTP, and it sends back finished slides. The "agent-native" part means it is built to be called by code or by an AI agent as one step in a larger run, not clicked through by a person.

heydecks is the example I know best, because I build it. heydecks is the AI slide creator that AI agents call over REST or MCP. From a prompt, markdown, or a URL it returns a live deck link, a PDF, and a native, editable PowerPoint, every export locked to your brand by the Brand Kernel, which it can extract from a URL. The difference from the add-in is the trigger and the place: the add-in waits for a person inside PowerPoint, while the API waits for a call from a server.

One call to heydecks returns the live deck, the PDF, and the editable .pptx, on your brand. No editor is open while this happens.

#When should software call a deck API instead of the add-in?

Call the API when no one is in PowerPoint. If the deck has to be generated by a backend job, a scheduled workflow, or an agent acting on a user's behalf, the add-in cannot help: it has no app to run inside and no person to drive it. The API is the shape that fits when the deck is an output of a system rather than a document someone is editing.

The cases that push people here tend to rhyme. You are turning every new customer's onboarding data into a tailored deck. You are generating a weekly report for two hundred accounts and nobody is going to open two hundred files. You are wiring "make me a deck" into a product where the user never sees PowerPoint, only the result. In all of those, the win is not that the API writes better slides than a human; it is that it runs unattended, returns a real .pptx you can still edit later, and keeps every deck on the same brand without anyone policing fonts and colors by hand.

#Claude for PowerPoint add-in vs an agent-native deck API: which should you use?

Pick by who is driving and where the work happens. If a person is editing an open deck, the add-in wins; if software needs a finished deck back, the API wins. The table below lines up the two on the dimensions that actually decide it.

Neither row is the loser. The mistake is forcing one tool to do the other's job: scripting against the add-in (there is no endpoint), or asking an API to be your interactive slide editor when you would rather just nudge things by hand. Match the tool to who is at the keyboard, or whether anyone is.

#How do you call a deck API from Claude or an agent?

You wire it up two ways, depending on whether Claude is in the loop or not. The first is MCP, where Claude itself designs the deck and calls the tools. Connect the heydecks MCP server once:

claude mcp add --transport http heydecks https://heydecks.com/mcp

Then ask in plain language, and Claude reads the slide schemas, writes every word itself, builds the deck, and publishes it to a live /d/<slug> link. heydecks is a structured store, not a second writer; your model's words go in, the file comes out.

The second way is the REST API, for pipelines where no one is driving Claude interactively. You post a prompt and poll a job:

curl -X POST https://heydecks.com/v1/generate \
  -H "Authorization: Bearer hd_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Q3 board update: revenue up 18%, three risks, ask for budget approval",
    "brand_id": "brand_abc"
  }'

That returns a job_id. Poll GET /v1/jobs/{id} until it succeeds, and the payload hands you the deck's live URL; the PDF and the editable .pptx are then free exports from that deck. The full API and MCP docs cover auth, the generate-and-poll loop, and the slide tools.

#Can you use both, the add-in and an API?

Yes, and plenty of teams will. They solve adjacent problems, so the line between them is clean: let an agent call the API to generate the first draft at scale, then have a person open that .pptx and finish it with the add-in. The file the API returns is a real, editable PowerPoint, so nothing about the handoff is lossy.

If your actual question is the broader "how do I get a deck out of Claude in the first place," I wrote that up separately: start with how to make a PowerPoint with Claude, which walks through every route from copy-paste to a real file. And if you want the agent side specifically, connecting Claude over MCP covers what the model can drive once it has tools. This post is the narrower decision: a human in the editor, or software with no editor at all.

Here is a deck heydecks generated straight from a URL, rendered on a sample brand. Page through it to see what comes back from a single call.

To try the agent path, point your pipeline at the REST API, wire Claude to the heydecks MCP server, and read the API and MCP docs for the generate-and-poll loop.

#Frequently asked questions

#Can Claude AI do PowerPoint?

Yes, in two distinct ways. With the Claude for PowerPoint add-in, a person edits a deck conversationally inside the app on a paid plan. Separately, an agent or script can call a deck API like heydecks to generate a branded, editable .pptx with no one in PowerPoint. The add-in is for editing; the API is for automated generation.

#Does Claude work directly in PowerPoint?

The add-in does. It runs in the PowerPoint sidebar, reads your open deck's masters, fonts, and layouts, and makes native edits in place. Outside that add-in, Claude in a plain chat cannot hand you a .pptx; to get a file from a prompt or an agent run, you connect it to a tool such as heydecks over MCP or REST.

#Is Claude for PowerPoint free?

No. The add-in is on the paid Pro, Max, Team, and Enterprise Claude plans, not the free tier, and you install it from the Microsoft Marketplace. Generating a deck through the heydecks API or MCP costs 100 credits, and the PDF and .pptx exports from that deck are free.

#When should I use a deck API instead of the add-in?

Use the API whenever no human is in PowerPoint: backend jobs, scheduled workflows, or an agent generating decks on a user's behalf. Use the add-in when a person is editing an existing deck by hand. If you need many decks generated unattended and returned on-brand, that is the API's job, not the add-in's.

#Does the deck API return a real editable PowerPoint?

Yes. heydecks returns a native, editable .pptx, not a flat image or a browser-only view, so anyone can open it in PowerPoint afterward and keep editing, including with the Claude add-in. Every export is locked to your brand by the Brand Kernel, which can be extracted from a URL.