Create a Project Status Update with a Slides MCP Server

A project status presentation should distinguish what has happened from what still needs checking. A Slides MCP server can help an assistant create the deck and update its text, but you still need to review the source, inspect the saved slides and check their visual layout.

This tutorial uses AppStruct Slides to create a five-slide update from fictional project notes. You will inspect slide IDs and speaker notes, replace the body of one selected slide and verify that the other slides stayed intact. The project and check results are teaching inputs, not customer outcomes or evidence that a production app passed those checks.

Prepare two snapshots of fictional project notes

Download the project-status practice notes. The file describes DEMO-STATUS-001, a service-request pilot with a form, team list and detail view. Give the text to your assistant as the source for this exercise; no document-import or automatic connection to another app is required.

The file contains two clearly labeled snapshots. Use Snapshot A for the first deck, and reserve Snapshot B for the later update. Otherwise, the assistant might mix a later change into the initial report.

Neither snapshot agrees on a budget, data store or launch date. Both leave action due dates as Not agreed, and neither approves a customer launch. Keep these unknowns visible instead of turning them into confident dates or a “ready to launch” claim.

Plan five slides and separate notes from visible text

Use this small outline before creating anything:

The example uses the titleBody layout throughout. That layout has a title slot and one body slot; it does not have a subtitle slot. Each body entry is one plain-text line. Bullets come from the layout, so do not add - or bullet characters to every string.

Speaker notes carry supporting context, rather than another copy of every slide. Read them explicitly during verification: a presentation overview leaves them out by default.

Connect the Slides MCP server and close the editor before writes

Follow the Slides MCP connection guide to open the Slides API-key settings and configure a compatible client. The endpoint is:

https://api.appstruct.cloud/v1/slides/mcp

Use Streamable HTTP and the Authorization: Bearer YOUR_APPSTRUCT_SLIDES_API_KEY header in your client's connection settings. The complete exercise needs slides:read and slides:write. Read permission lets you inspect the result; write permission lets you create and change it. Refresh tool discovery after changing a key's scopes.

Work with a presentation owned by your account in the workspace associated with the key. Presentations shared with that account are not reachable through this API-key view.

Before making API edits, close the presentation in every browser editor tab. An open editor can save its own copy over an MCP change, and it does not automatically display that change. Reopen the deck after the write and read-back. These MCP tools do not expose version-history or undo operations. Do not rely on an editor undo stack to recover an external overwrite; use a separate practice presentation.

The tools used below are create_presentation, get_presentation, get_slide and set_slide_content. Use list_presentations if you need to locate a saved practice deck by title before continuing.

Review the deck content, then create it once

Start with this request:

Read Snapshot A only. Propose five titleBody slides in this order: Goal, Progress, Risks, Next steps and Decisions needed. Keep the check IDs and states from Snapshot A. Put supporting context in speaker notes. Keep unspecified dates, budget and data store as “Not agreed”. Show the complete proposed content before creating one separate practice presentation. Do not use Snapshot B yet.

Check the proposal against the source table above. In particular, DEMO-CHECK-02 and DEMO-CHECK-03 must still say Not checked. After reviewing the draft, create_presentation can receive these complete example arguments:

{
  "title": "Project update - DEMO-STATUS-001 - practice",
  "size": "16:9",
  "slides": [
    {
      "layout": "titleBody",
      "title": "Goal",
      "body": [
        "Test submitting a service request and reviewing it as a team",
        "Scope: form, team list and detail view with a targeted status update"
      ],
      "notes": "Source: DEMO-STATUS-001, Snapshot A. This is a fictional teaching project."
    },
    {
      "layout": "titleBody",
      "title": "Progress",
      "body": [
        "DEMO-CHECK-01: Save and reopen - completed in the fictional rehearsal",
        "DEMO-CHECK-02: Targeted status update - not checked",
        "DEMO-CHECK-03: Failed write and retry - not checked"
      ],
      "notes": "These are fictional exercise states, not customer outcomes or production test evidence."
    },
    {
      "layout": "titleBody",
      "title": "Risks",
      "body": [
        "Retrying a submission could create a duplicate request",
        "The failed-write and retry check has not been performed"
      ],
      "notes": "Keep the retry risk open until the specified check has been reviewed."
    },
    {
      "layout": "titleBody",
      "title": "Next steps",
      "body": [
        "Example A: Review who may read and update request details",
        "Example B: Run the failed-write and retry check",
        "Both due dates: Not agreed"
      ],
      "notes": "Assigned tasks are next steps, not proof that permissions or retry behavior have been verified."
    },
    {
      "layout": "titleBody",
      "title": "Decisions needed",
      "body": ["Data store: Not agreed", "Budget: Not agreed", "Target launch date: Not agreed"],
      "notes": "This exercise does not approve a customer launch."
    }
  ]
}

The tool returns a presentation ID and the IDs of the created slides. Keep those IDs for reading and editing; slide numbers describe the current order and can change when slides are inserted or moved.

If the response is interrupted, inspect the presentation list before repeating creation. Another create_presentation call creates another deck; a missing response does not establish that the first call saved nothing.

Read all five slides, including speaker notes

Use the returned presentation ID with get_presentation:

{
  "presentation_id": "YOUR_PRESENTATION_ID",
  "include_notes": true
}

Confirm the five titles and their order, record each slide's ID and check every state against Snapshot A. Verify that the unknowns remain unknown and that the speaker notes describe a fictional exercise.

This is a bounded overview, rather than an unlimited copy of every slide. It shows at most eight lines from a text slot and can shorten long lines or notes. For long decks, follow the returned start_slide value to read later pages. A shortened result is not suitable replacement text.

Now inspect the Progress slide using its actual ID:

{
  "presentation_id": "YOUR_PRESENTATION_ID",
  "slide_id": "YOUR_PROGRESS_SLIDE_ID"
}

get_slide returns the element inventory, current text, notes and writable layout slots. Check that this is the Progress slide and that its layout is titleBody. If a response marks a line as shortened with an ellipsis, do not write that displayed fragment back over the original. Keep the approved source text available and resolve the full intended content before editing.

Update only the Progress body from Snapshot B

Snapshot B changes one check's state. Ask the assistant to show a proposed update for the Progress body, while retaining all three checks. Keep the title, speaker notes, slide order and every other slide unchanged. Close any editor tab opened during inspection before allowing the API write.

After reviewing the proposal, these are the set_slide_content arguments:

{
  "presentation_id": "YOUR_PRESENTATION_ID",
  "slide_id": "YOUR_PROGRESS_SLIDE_ID",
  "body": [
    "DEMO-CHECK-01: Save and reopen - completed in the fictional rehearsal",
    "DEMO-CHECK-02: Targeted status update - completed in the fictional rehearsal",
    "DEMO-CHECK-03: Failed write and retry - not checked"
  ]
}

Replace both ID placeholders with the discovered values. This replaces the entire body slot; sending only the new DEMO-CHECK-02 line would remove the other two lines. Slots omitted from the request stay untouched, while an empty string or empty list clears the slot it addresses.

Read the Progress slide again, then read the complete deck with notes. Check these specific results:

• DEMO-CHECK-02 now says Completed in the fictional rehearsal.
• DEMO-CHECK-01 and DEMO-CHECK-03 keep their previous states.
• The Progress title and speaker notes are unchanged.
• There are still five slides in the same order with the same slide IDs.
• Risks, owners, due dates, decisions and launch state remain as before.

This is an exercise in applying a fictional source update. It does not claim that an actual app passed the targeted-update check.

Reopen the presentation for a visual review

Open AppStruct Slides and reopen the saved practice deck. Review each slide at its intended presentation size. Check that the title and body fit, the text is readable, the lines appear in the right order and the notes are in the expected slides.

A successful text read-back does not establish that a slide looks good. Shorten the reviewed wording or adjust the design in the editor where necessary. The MCP tools do not insert images, change geometry, fonts or colors, or export PDF/PPTX. Use the browser editor for visual work and its available export options.

If you return to MCP editing after a visual review, close the editor again first. Avoid alternating writes between a stale editor tab and the assistant.

Diagnose a result before retrying it

The Slides API reference and OpenAPI document describe the API and available MCP tools. Current write ceilings include 400 slides per deck, 200-character titles, 500 body lines per slot and 20,000 characters per line or speaker note. Those are technical ceilings, not design targets; this exercise keeps each slide short enough to inspect.

Continue with the right source workflow

For a written brief before the presentation, follow the Docs MCP meeting-notes tutorial. For a structured table of requests and statuses, try the Sheets MCP tracker. Each uses its own source and verification steps; creating this deck does not automatically link it to Docs or Sheets.

Explore AppStruct Workspace or return to the Slides MCP setup guide to apply the same review sequence to another small, explicit presentation task.