160+ finished slide layouts and 41 themes your agent can search, fetch and build a deck from
Scored across 15 tools
Each tool has a distinct resource and action: layouts are listed/retrieved, themes listed/retrieved, templates listed/retrieved/saved/updated, and slide objects added/updated/removed. The descriptions explicitly steer ambiguous cases (e.g. use add_objects instead of update_template for placing objects, use suggest_deck instead of list_layouts for whole decks).
All 15 tool names use consistent snake_case verb_noun patterns such as list_layouts, get_template, update_objects, and export_pptx. No mixed conventions or vague naming.
15 tools is at the upper end of the ideal range but well-suited to the deck-building domain, covering discovery, composition, object editing, persistence, and export. Each tool appears to earn its place without obvious redundancy.
The surface covers core workflows: discover layouts/themes, compose a deck, edit slide objects, save/update/export templates, and list media. Minor gaps exist because template and slide deletion are only available on the web, and media cannot be uploaded or fetched via the MCP server, though these limitations are documented.
Add text boxes and images on top of one slide of a saved template, up to 50 per call and 50 per slide. Requires a Pro account. Use this instead of update_template to place objects: it never touches slots, other slides or other objects. Each item is {type:"text", text, ...} or {type:"image", asset, ...}; position and size are optional (a text box lands near the middle, an image is centered and fitted). Coordinates are pixels on a 1920x1080 slide and are kept inside it. Colors are theme tokens, not hex. Images come only from list_media ids. Set behind:true to put an object under the layout's own title and text (a background picture behind the default title); it is hidden wherever a layout card or panel has a solid fill. All items are added or none. Returns the slide's objects with their ids and the new version. Errors: pro_required, not_found, conflict (read again with get_template and retry), invalid_input.
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| slide_id | Yes | The slide's id from get_template. | |
| template_id | Yes | From list_templates. | |
| expected_version | No | The version from get_template. Given, the call fails with conflict if the template changed since. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does: 50-per-call/slide caps, Pro gating, atomic all-or-none semantics, default placement and fitting behavior, coordinate clamps to the slide, the behind-layer caveat where solid fills hide the object, and the returned payload. It also lists named error codes and tells the agent to re-read with get_template and retry on conflict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: limits and the sibling comparison come first, then item shape, coordinates, colors, assets, layering, atomicity, return value and errors. It is a long paragraph, and splitting the error list from the behavioral prose would aid scanning, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description states what is returned ('the slide's objects with their ids and the new version'), and it covers rate/size limits, atomicity, prerequisites, defaults and error recovery for a four-parameter mutation with nested item objects. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description still adds meaning beyond it: position and size are optional with stated defaults ('a text box lands near the middle, an image is centered and fitted'), colors are theme tokens rather than hex, images must come from list_media ids, and behind:true is explained along with the solid-fill caveat. It does not cover expected_version, which the schema handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Add text boxes and images on top of one slide of a saved template') and immediately bounds the scope ('it never touches slots, other slides or other objects'), which separates it from update_template and update_objects without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes away from update_template for placing objects and states the Pro-account prerequisite. It does not distinguish itself from update_objects or remove_objects, so the add-vs-modify choice is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a deck into a downloadable .pptx file. Requests like "make it a PowerPoint", "PPT로 뽑아줘", or "export this deck" mean this tool. Takes the layout ids and the text for each slot, and returns a signed download link. Coordinates come from our measurements, so the file matches what the gallery shows, but the boxes are fixed, so text longer than slots[].max_chars will be clipped.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Theme id. Only measured themes work; omit to use the default. A My Theme id ("custom:...") from list_themes also works: its base theme's layout with the user's colors. | |
| slides | No | Up to 25 slides, in order. Required unless template_id is given. | |
| embed_fonts | No | Put the fonts inside the file so it looks the same where they are not installed. On by default; pass false to leave them out. The result lists fonts that could not be embedded. | |
| template_id | No | A saved template id from list_templates. Exports that template with its own theme and slides; theme and slides are then ignored. Errors for it: not_found, template_lookup_failed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the return value (a signed download link), the determinism guarantee (coordinates from our measurements, matching the gallery), and a real failure mode (text exceeding slots[].max_chars is clipped, not reflowed). It omits permissions, latency/async behavior and error surface, which are non-trivial for a file-generation call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then trigger phrases, then the hard constraint. No filler and no restatement of the title; the clipping warning is placed where an agent will see it before building arguments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, no-output-schema, no-annotation export tool, the description covers what is produced, how fidelity is guaranteed, and the main correctness trap. Gaps are the operational envelope: no mention of whether export is synchronous or how the signed link expires, and no error guidance beyond what the schema lists for template_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns one above that by stating the operational consequence of slots text length (silent clipping at max_chars) and by explaining that layout ids plus per-slot text are the core input pair. The theme/template_id override relationship is left to the schema to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact: 'Turn a deck into a downloadable .pptx file', then reinforces it with real user phrasings ("make it a PowerPoint", "PPT로 뽑아줘"). No sibling tool in the list performs export, so there is no ambiguity to resolve, and the agent can select it from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering utterances, which is stronger than most definitions and directly useful for intent routing. It stops short of explicit exclusions or prerequisites (e.g. that this is the terminal step after get_layout/list_themes, or that template_id bypasses the slides path), so the 'when not to use' side is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one layout as a ready-to-use, self-contained document: HTML, theme CSS, and its slot definitions. Call this once the user knows which layout they want, or with ids returned by suggest_deck.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| lang | No | Language for slot hints and usage notes. Pass the language the user is writing in. | ko |
| theme_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It describes the return payload but does not state side effects (or lack thereof) such as read-only behavior or error handling. It is not misleading, but leaves safety assumptions to the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the output, the second the usage condition. Information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description covers the output structure and the main usage trigger. However, it omits how lang and theme_id affect the result, and error behavior. Given the low schema coverage, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints that id comes from suggest_deck, but does not explain lang or theme_id. Schema coverage is only 33% (lang only), so the description should compensate but doesn't, leaving theme_id completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (return), the resource (one layout), and the contents (HTML, theme CSS, slot definitions). It also differentiates from siblings by naming suggest_deck as a source for ids, implying this is for a specific chosen layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call when the user knows which layout they want, and mentions using ids from suggest_deck. This gives clear context for invocation, though it doesn't explicitly mention when not to use it or alternatives like list_layouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this when joining several fetched layouts into one deck file. Requests like "merge these into one file", "bundle it as a deck", or "make it one HTML" mean this tool. Returns the base CSS, assembly rules, spacing tokens, and a viewport snippet for standalone viewing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states that the tool returns certain components, implying a read-only operation, but does not explicitly confirm side-effect-free behavior or any limitations. The lack of annotation coverage means the description provides only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with a clear role: the first states when to use, the second lists the return value. Information is front-loaded and there is no filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description must explain what the tool returns, which it does by enumerating the returned components. However, it does not describe the structure or format of these components, which might be needed for parsing. Given the tool's simplicity (no params), this is nearly complete, but a bit more detail on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% (no params), so the baseline is 4. The description adds no parameter-specific information because none exists, but it doesn't need to. It correctly implies the tool takes no input, so the score aligns with the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: joining several fetched layouts into one deck file. It also lists the return payload (base CSS, assembly rules, spacing tokens, viewport snippet), making the function unambiguous. It distinguishes itself from siblings like get_layout (single layout) and list_layouts (listing) by focusing on bundling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage triggers with example phrasings ('merge these into one file', 'bundle it as a deck', 'make it one HTML'). It clearly indicates when to call the tool, but does not explicitly mention alternatives or when not to use it, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one saved template: name, theme_id and slides as [{id, layout, slots, objects, overrides?}], plus each slide's slot definitions with max_chars. Use it to fill the same structure with new text, then save with update_template or export with export_pptx(template_id), both of which need Pro. To place or change only the objects of one slide, use add_objects, update_objects and remove_objects. Needs an API key; reading works on any plan.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose auth ('Needs an API key') and plan gating ('reading works on any plan' while update/export need Pro) — genuinely non-obvious behavior. It stops short of covering failure modes such as a missing or invalid template id and whether the payload is truncated for large decks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return shape, and every subsequent sentence (fill-then-save, slide-level alternatives, auth/plan) earns its place. The return-shape clause is a dense run-on, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so describing the return structure is essential and largely done here, including which slide fields are optional. Gaps remain around error behavior and response size, but the core read path is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single id string is undocumented in the schema, so the description should compensate. It only implies the parameter is a template id via 'export_pptx(template_id)'; it never says where the id comes from (list_templates) or whether it expects a UUID or slug.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (return one saved template) and then enumerates the return shape: name, theme_id, slides as [{id, layout, slots, objects, overrides?}] plus slot max_chars. That level of specificity clearly separates it from list_templates and get_layout without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the follow-on path explicitly (fill the structure, then update_template or export_pptx(template_id)) and routes slide-level edits to add_objects/update_objects/remove_objects. Both a when-to-use and a when-to-use-something-else are given, leaving little inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one theme in full: its complete CSS and design tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It transparently states the return payload includes complete CSS and design tokens, but it does not address not-found behavior, data source, or side-effect profile (even though 'get' implies a read).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every phrase ('one theme', 'complete CSS', 'design tokens') adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool this is mostly sufficient, but with no output schema and no parameter documentation, the description should state the id semantics and suggest how to discover ids. The omission leaves minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the id parameter beyond the schema's type: string. It implies the id selects a theme, but does not specify what form the id takes or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Return') and a specific resource ('one theme in full', including complete CSS and design tokens). This clearly distinguishes it from list_themes and get_layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use or when-not-to-use guidance and does not mention alternatives such as list_themes for enumerating themes or get_layout for layout assets. Usage context must be inferred from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or filter the layout catalog to find a specific layout. Returns metadata only, no HTML. Also the tool for "what is new", "any new layouts?", "what got added since last month" - pass since and it returns only what landed after that date. If the user asked for a whole deck rather than one slide, call suggest_deck first instead of this.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| since | No | ISO date (YYYY-MM-DD). Only layouts added after it. Use for "what is new" questions; if the user gave no date, a month back is a sensible default. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses key behavior: 'Returns metadata only, no HTML' and that `since` filters to layouts added after the date. It does not mention sorting, pagination, or rate limits, but the disclosed return-type and filtering behavior are significant and add value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first gives the core purpose, the second covers the `since` use case, and the third redirects to suggest_deck. It is concise, front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, return type, a key parameter, and an alternative tool, which is adequate for basic use. However, it leaves gaps: no distinction from get_layout, no semantics for query/category/limit, no output format details, and no pagination/sorting behavior, which matters more because there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only `since` has a schema description). The tool description reinforces `since` but does not explain what `query` matches, what `category` values are valid, or how `limit` behaves beyond the schema defaults. With such low coverage, the description fails to compensate for the three undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search or filter the layout catalog') with a clear resource and scope ('find a specific layout'), and adds the 'what is new' role via the `since` parameter. It also distinguishes itself from suggest_deck by explicitly naming that sibling, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use it to search/filter the catalog and for 'what is new' questions with `since`. It also gives a clear when-not-to-use rule: if the user wants a whole deck, call suggest_deck first instead, naming the alternative and the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the images the user uploaded to their media library on the web: id, name, width, height, aspect_ratio (width/height), bytes, mime and created_at, newest first, plus used_bytes. Pass an id to add_objects to place the picture on a slide. You cannot upload an image or fetch one from a web address; if the picture you need is missing, ask the user to upload it to their media library on the web. Needs an API key; works on any plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it states ordering ('newest first'), that no upload or web fetch is possible, and that an API key is required but any plan works. It does not state pagination or result limits, which is a minor transparency gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and return fields, then follows with usage and constraints. The first sentence is quite dense with a long field list, but every element is relevant and the text avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must supply everything. It does: what the tool lists, the fields returned, ordering, auth requirements, and the functional limitation that images cannot be uploaded or fetched by URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero input parameters, so the baseline is 4. The description adds useful return-side semantics by specifying the fields returned and how the id is used with add_objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List the images the user uploaded to their media library on the web.' It also distinguishes this listing tool from the sibling add_objects by explaining that the returned id is what add_objects consumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage path clear: call this to get image ids, then pass an id to add_objects. It also covers the missing-image case by telling the agent to ask the user to upload, though it does not explicitly name alternatives or exclusions beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the templates the user saved in My Templates: id, name, slide_count, theme_id, source, updated_at and version. Use it to find a template the user refers to, and to read slide_count before appending with update_template. Needs an API key; works on any plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the auth requirement ('Needs an API key') and plan availability ('works on any plan'). It also names the returned fields, which substitutes for the missing output schema. It says nothing about pagination or result-size limits for a list endpoint, which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and scope, then the routing guidance and auth note. The field enumeration is dense but earns its place since there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no annotations and no output schema, the description covers the essentials: what is listed, what fields come back, what it is for, and the API-key requirement. Only pagination/volume behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline rule a 4 applies. Nothing about the empty schema needs compensating, and the description correctly does not invent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'List the templates the user saved in My Templates.' The enumerated return fields (id, name, slide_count, theme_id, source, updated_at, version) make it clearly distinct from list_themes, list_layouts, and get_template without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: find a template the user refers to, and read slide_count before appending with update_template, which routes the agent to the correct follow-up tool. It does not, however, state when not to use it (e.g., versus get_template for a single template's details), so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or filter the theme catalog. Returns metadata and key colors only, not the full CSS. With an API key, the user's own saved themes (My Themes, id "custom:...") come last with custom: true; their ids work anywhere a theme id does.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | ||
| scheme | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that output is deliberately truncated to metadata and key colors, not full CSS, and that API-key presence changes results (saved themes appended with custom: true and reusable ids). It omits pagination, ordering beyond the custom tail, and error behavior, so it is good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded: the catalog-search purpose leads, then return-scope limits, then the auth-dependent behavior. Three clauses, no filler, though the final clause about custom ids packs several ideas into one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param read tool with no annotations and no output schema, the description usefully compensates on the return side by stating what is and isn't returned. The remaining hole is parameter meaning — mood and scheme are wholly undocumented anywhere — which is significant given 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters, yet it explains nothing about "mood" (a free-form string with no stated vocabulary) or "scheme" (light/dark). "Search or filter" only vaguely implies filter parameters exist; an agent cannot tell what values mood accepts or how the two filters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Search or filter the theme catalog") and clarifies the return scope (metadata and key colors only, not the full CSS). It reads as a catalog-listing complement to the sibling get_theme, but it never names that sibling or explicitly draws the list-vs-single boundary, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Search or filter the theme catalog" implies the browse/discovery use case, and the custom-theme note hints the tool is useful for surfacing a user's own themes. However, there is no explicit when-to-use versus get_theme, no stated prerequisites, and no exclusions, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove objects from a slide by id. Requires a Pro account. The slide, its slots and the other objects stay. Only objects can be removed here; slides and templates are deleted on the web. If any id is not on the slide, nothing is removed. Returns the objects that remain and the new version. Errors: pro_required, not_found, conflict (read again with get_template and retry), invalid_input.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| slide_id | Yes | The slide's id from get_template. | |
| template_id | Yes | From list_templates. | |
| expected_version | No | The version from get_template. Given, the call fails with conflict if the template changed since. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the Pro-account prerequisite, atomicity ('If any id is not on the slide, nothing is removed'), what is preserved ('the slide, its slots and the other objects stay'), the return shape, and the full error set. This is unusually complete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action, then scope, then atomicity, then return, then errors. Every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param mutation tool with no annotations and no output schema, the description covers prerequisites, side effects, return values, and error handling. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the undocumented 'ids' param is covered by the description's 'by id' and atomicity note; 'expected_version' is indirectly explained via 'the new version' and the conflict guidance. It adds real meaning over the schema, though it could state the 1-50 id bound explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (remove) and resource (objects from a slide) scoped by id, and explicitly carves out what it does NOT handle (slides and templates are deleted on the web). This cleanly separates it from add_objects/update_objects and from slide/template mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not routing ('slides and templates are deleted on the web') and prescribes a recovery path for the conflict error ('read again with get_template and retry'). An agent knows both the boundary and the retry procedure without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a deck as a named template in the user's My Templates so it can be reused later. Requires a Pro account; without one the call fails and nothing is saved. Use it after you have built a deck the user wants to keep, for example from suggest_deck. Input: name, optional theme_id (a catalog theme id or custom:), and slides as [{layout, slots}], the same shape export_pptx takes. A template holds 1 to 25 slides. Returns template_id, url (the template's page), slide_count, version (use it as expected_version in update_template), overflow[] (slots whose text is longer than max_chars) and unknown_layouts[]. Deleting is not available here, only on the web. Errors: pro_required, slide_limit, template_limit (the account already has the most templates it can hold), unknown_theme, invalid_input.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| slides | Yes | ||
| theme_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so: Pro gating and its failure behavior, the 1-to-25 slide bound, the returned fields (template_id, url, slide_count, version, overflow[], unknown_layouts[]) and their downstream use (version as expected_version). It even enumerates error codes including template_limit and pro_required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then prerequisites, inputs, outputs, and errors in that order. It is dense but every clause is informational; the input/output/errors run-on sentences could be broken up slightly for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations exist, yet the description explains return values, error modes, account requirements, and the fact that deletion lives elsewhere. An agent has everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema parameters have no descriptions (reported 0% coverage), and the description fills the most important gaps: theme_id accepts a catalog theme id or 'custom:<uuid>', slides use the same [{layout, slots}] shape as export_pptx, and the slide count is bounded. It does not explain the required name constraints or the interplay of objects/overrides, though the nested schema already documents those richly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: saving a deck as a named template in the user's My Templates, with the reuse motivation. It is clearly distinguishable from siblings—update_template is referenced via the returned version, and deletion is explicitly routed to the web rather than a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives timing ('after you have built a deck the user wants to keep, for example from suggest_deck'), a prerequisite ('Requires a Pro account; without one the call fails and nothing is saved'), and excludes a capability ('Deleting is not available here, only on the web'). No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose a deck and return a preview link the user can open in the browser right away. The user sees what the finished deck looks like without a single file being generated. Use this for requests like "make me a pitch deck", "I need a sales deck", "10 slides for an investor update", "put together a product overview", or "show me a deck outline" - anything where the user has a topic but has not picked layouts yet. ALSO use it when the user already has layouts in hand - "이 레이아웃들 모아서 프리뷰 만들어줘", "combine these layouts into a preview", "추천 프리뷰 만들어줘", "show these together as a deck" - pass them as layout_ids and it returns ONE deck preview link for the whole set. Never answer that kind of request with a list of individual layout links: one deck preview is the deliverable. Returns one theme + a slide order + the preview link, plus a clarify question to put to the user so the composition and theme are their call, not a guess. Always pass the preview link through to the user verbatim, ask clarify.question with its options, and wait for the answer - then call this tool again with deck_id / theme_id as clarify.answer_with says. Do not start generating files while a clarify question is unanswered. Once it is settled, fetch each layout id with get_layout, then call get_starter_kit to join them into one deck.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Desired mood. e.g. "minimal", "bold", "warm". Omit if the user did not mention one. | |
| deck_id | No | The composition the user picked from a previous call's clarify.options. Skips topic matching. | |
| purpose | Yes | The user's topic or goal, in their own words. e.g. "startup pitch deck", "quarterly business review" | |
| theme_id | No | The theme the user picked from a previous call's clarify.options. Pass deck_id along with it. | |
| layout_ids | No | Layout ids the user or you already picked, in slide order. Skips topic matching and slide_count: the preview link is built from exactly these layouts. | |
| slide_count | No | How many slides. If the user did not say, use the default of 10 rather than asking. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It does disclose that the tool is non-destructive (does not generate files), that it returns a single preview link, and that it asks a clarify question. However, it does not specify any side effects beyond not generating files, nor does it mention authorization/rate limits. Given the absence of annotations, the description partially carries the burden but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long and includes many procedural details that could be seen as part of the tool's usage rather than just a description. While it is well-structured with clear sections, it is verbose and could be trimmed without losing essential information. The main purpose is stated early, but the length reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, which raises the bar for completeness. The description covers the main workflow, the clarify interaction, and the use of get_starter_kit. However, it does not detail what the preview link looks like or if there are any constraints on the number of layout_ids (such as matching slide_count). Still, given the complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds operational meaning by explaining that deck_id and theme_id come from prior clarify.options and that layout_ids causes the tool to skip topic matching. This goes beyond the schema's static definitions and helps the agent understand how parameters relate to the tool's stateful workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool composes a deck and returns a preview link without generating files. It gives multiple concrete example requests, including both topic-based and layout-based use cases, and explicitly contrasts with returning individual layout links. This distinguishes it sharply from its siblings like get_layout (fetch a single layout) and get_starter_kit (join layouts into a deck).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios with example phrases, and also says 'ALSO use it' for the layout combining case. It also tells the agent what NOT to do (never answer with list of individual layout links) and gives a step-by-step workflow involving calling get_layout and get_starter_kit. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change objects already on a slide, by id: position, size, rotation, text, text style, the image's alt text or picture, stacking order, and behind (true sends it behind the layout's own elements, false brings it back in front). Requires a Pro account. Send only the fields to change; the style is merged. An image keeps its proportions (send w alone). Up to 50 changes per call, all applied or none. Read ids and the current version with get_template. Returns the slide's objects and the new version. Errors: pro_required, not_found, conflict (read again with get_template and retry), invalid_input.
| Name | Required | Description | Default |
|---|---|---|---|
| changes | Yes | ||
| slide_id | Yes | The slide's id from get_template. | |
| template_id | Yes | From list_templates. | |
| expected_version | No | The version from get_template. Given, the call fails with conflict if the template changed since. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses the Pro-account requirement, atomic all-or-none application, 50-change limit, style merging, image aspect-ratio behavior, behind/order semantics, return value, and error codes including conflict recovery.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: it starts with the action and fields, then moves through requirements, constraints, return value, and errors. Every clause contributes useful information for invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with no annotations and no output schema, the definition is complete enough: it explains atomicity, Pro requirements, version conflicts, return value, and error handling. An agent has what it needs to call and recover from failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 75%, so the schema documents most parameters. The description adds meaningful semantics beyond it, especially "Send only the fields to change; the style is merged," the image w-alone behavior, and the behind/order interaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Change objects already on a slide") and enumerates the changeable attributes. The phrase "already on a slide" clearly distinguishes it from add_objects and remove_objects without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational context: requires a Pro account, use ids from get_template, send only fields to change, and retry with get_template on conflict. It does not explicitly name add_objects or remove_objects as the alternatives for adding or removing objects, so it falls just short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a template the user already saved. Requires a Pro account; without one the call fails and nothing is changed. Pass the template id and any of: name, theme_id, slides (replaces all slides), or append_slides (adds slides to the end). A template holds at most 25 slides. If the result would be more than 25, nothing is changed and the response is a slide_limit error that includes how many slides still fit. Call list_templates first to read slide_count when you plan to append. The response has the same fields as save_template. Deleting is not available here, only on the web. Errors: pro_required, not_found, slide_limit, conflict (the template changed since expected_version, or kept changing during an append; nothing was saved), unknown_theme, invalid_input.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| slides | No | ||
| theme_id | No | ||
| append_slides | No | ||
| expected_version | No | The version from get_template or a previous save. Given, the call fails with conflict if the template changed since. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: Pro gating, atomic all-or-nothing semantics ("nothing is changed"), the 25-slide cap with a slide_limit error that reports remaining capacity, and conflict semantics around expected_version. It also discloses the response shape ("same fields as save_template") and enumerates every error code with meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the account precondition, then the mutation modes, then limits, then the error list. Every sentence adds a distinct operational fact; nothing is restated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter mutation tool with no annotations and no output schema, the definition covers preconditions, atomicity, limits, concurrency, return shape, and error handling. An agent can call this correctly and recover from failures without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema coverage is only 17%, yet the description supplies the missing semantics for the critical parameters: slides replaces all slides, append_slides appends, and the conflict behavior of expected_version. The replacement-vs-append distinction is not derivable from the schema and is the main correctness risk here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus a scope constraint: "Change a template the user already saved," which implicitly separates it from save_template (creation). It never names save_template or get_template as alternatives for routing, so sibling differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not: requires Pro (with failure behavior), "Call list_templates first to read slide_count when you plan to append," and "Deleting is not available here, only on the web." It also distinguishes the two ways to change slides (slides replaces all vs append_slides adds to the end).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_objectsexport_pptx1 field changedInput schema / properties / embed_fonts / descriptionPrevious value: -"Put the fonts inside the file so it looks the same where they are not installed. Off unless set. The result lists fonts that could not be embedded."New value: +"Put the fonts inside the file so it looks the same where they are not installed. On by default; pass false to leave them out. The result lists fonts that could not be embedded."list_mediaremove_objectssave_template3 fields changedInput schema / properties / slides / items / properties / idAdded value: +{
+ "description": "The slide's id from get_template. Keep it when you resend a slide; leave it out for a new slide and the server assigns one.",
+ "type": "string"
+}Input schema / properties / slides / items / properties / objectsAdded value: +{
+ "description": "Images and text boxes laid over the slide, in 1920x1080 pixels. Resend the objects you got from get_template or they are removed. At most 50 per slide.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "alt": {
+ "description": "For type \"image\": a short description of the picture for screen readers (up to 300 characters).",
+ "type": "string"
+ },
+ "asset": {
+ "description": "For type \"image\": the id of an image in the user's media library.",
+ "type": "string"
+ },
+ "behind": {
+ "description": "true: drawn behind the layout's own elements, on top of the slide background. Absent or false: in front of the layout.",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "rotate": {
+ "type": "number"
+ },
+ "style": {
+ "additionalProperties": {},
+ "properties": {
+ "align": {
+ "type": "string"
+ },
+ "color": {
+ "description": "A theme token name such as \"ink\" or \"accent\", not a color value.",
+ "type": "string"
+ },
+ "size": {
+ "type": "number"
+ },
+ "weight": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "text": {
+ "description": "For type \"text\".",
+ "type": "string"
+ },
+ "type": {
+ "description": "\"image\" or \"text\".",
+ "type": "string"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ },
+ "z": {
+ "description": "Stacking order; larger is in front. Each layer (see behind) is ordered on its own.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "type",
+ "x",
+ "y",
+ "w",
+ "h",
+ "z"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / slides / items / properties / overridesAdded value: +{
+ "additionalProperties": {
+ "additionalProperties": {},
+ "properties": {
+ "deleted": {
+ "description": "true: the element is not drawn on this slide (not in the export either).",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "description": "Changes to the layout's own elements, by element key: { \"top-accent-bar\": { \"deleted\": true }, \"title\": { \"x\": 40, \"y\": 62 } }. Only the values that changed are given; x, y, w, h are pixels on the 1920x1080 slide and the rest stays as the layout draws it. Resend the overrides you got from get_template or they are removed. Requires Pro.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}update_objectsupdate_template6 fields changedInput schema / properties / append_slides / items / properties / idAdded value: +{
+ "description": "The slide's id from get_template. Keep it when you resend a slide; leave it out for a new slide and the server assigns one.",
+ "type": "string"
+}Input schema / properties / append_slides / items / properties / objectsAdded value: +{
+ "description": "Images and text boxes laid over the slide, in 1920x1080 pixels. Resend the objects you got from get_template or they are removed. At most 50 per slide.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "alt": {
+ "description": "For type \"image\": a short description of the picture for screen readers (up to 300 characters).",
+ "type": "string"
+ },
+ "asset": {
+ "description": "For type \"image\": the id of an image in the user's media library.",
+ "type": "string"
+ },
+ "behind": {
+ "description": "true: drawn behind the layout's own elements, on top of the slide background. Absent or false: in front of the layout.",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "rotate": {
+ "type": "number"
+ },
+ "style": {
+ "additionalProperties": {},
+ "properties": {
+ "align": {
+ "type": "string"
+ },
+ "color": {
+ "description": "A theme token name such as \"ink\" or \"accent\", not a color value.",
+ "type": "string"
+ },
+ "size": {
+ "type": "number"
+ },
+ "weight": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "text": {
+ "description": "For type \"text\".",
+ "type": "string"
+ },
+ "type": {
+ "description": "\"image\" or \"text\".",
+ "type": "string"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ },
+ "z": {
+ "description": "Stacking order; larger is in front. Each layer (see behind) is ordered on its own.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "type",
+ "x",
+ "y",
+ "w",
+ "h",
+ "z"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / append_slides / items / properties / overridesAdded value: +{
+ "additionalProperties": {
+ "additionalProperties": {},
+ "properties": {
+ "deleted": {
+ "description": "true: the element is not drawn on this slide (not in the export either).",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "description": "Changes to the layout's own elements, by element key: { \"top-accent-bar\": { \"deleted\": true }, \"title\": { \"x\": 40, \"y\": 62 } }. Only the values that changed are given; x, y, w, h are pixels on the 1920x1080 slide and the rest stays as the layout draws it. Resend the overrides you got from get_template or they are removed. Requires Pro.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / slides / items / properties / idAdded value: +{
+ "description": "The slide's id from get_template. Keep it when you resend a slide; leave it out for a new slide and the server assigns one.",
+ "type": "string"
+}Input schema / properties / slides / items / properties / objectsAdded value: +{
+ "description": "Images and text boxes laid over the slide, in 1920x1080 pixels. Resend the objects you got from get_template or they are removed. At most 50 per slide.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "alt": {
+ "description": "For type \"image\": a short description of the picture for screen readers (up to 300 characters).",
+ "type": "string"
+ },
+ "asset": {
+ "description": "For type \"image\": the id of an image in the user's media library.",
+ "type": "string"
+ },
+ "behind": {
+ "description": "true: drawn behind the layout's own elements, on top of the slide background. Absent or false: in front of the layout.",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "rotate": {
+ "type": "number"
+ },
+ "style": {
+ "additionalProperties": {},
+ "properties": {
+ "align": {
+ "type": "string"
+ },
+ "color": {
+ "description": "A theme token name such as \"ink\" or \"accent\", not a color value.",
+ "type": "string"
+ },
+ "size": {
+ "type": "number"
+ },
+ "weight": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "text": {
+ "description": "For type \"text\".",
+ "type": "string"
+ },
+ "type": {
+ "description": "\"image\" or \"text\".",
+ "type": "string"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ },
+ "z": {
+ "description": "Stacking order; larger is in front. Each layer (see behind) is ordered on its own.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "type",
+ "x",
+ "y",
+ "w",
+ "h",
+ "z"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / slides / items / properties / overridesAdded value: +{
+ "additionalProperties": {
+ "additionalProperties": {},
+ "properties": {
+ "deleted": {
+ "description": "true: the element is not drawn on this slide (not in the export either).",
+ "type": "boolean"
+ },
+ "h": {
+ "type": "number"
+ },
+ "w": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "description": "Changes to the layout's own elements, by element key: { \"top-accent-bar\": { \"deleted\": true }, \"title\": { \"x\": 40, \"y\": 62 } }. Only the values that changed are given; x, y, w, h are pixels on the 1920x1080 slide and the rest stays as the layout draws it. Resend the overrides you got from get_template or they are removed. Requires Pro.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}export_pptx5 fields changedInput schema / properties / embed_fontsAdded value: +{
+ "description": "Put the fonts inside the file so it looks the same where they are not installed. Off unless set. The result lists fonts that could not be embedded.",
+ "type": "boolean"
+}Input schema / properties / slides / descriptionPrevious value: -"Up to 25 slides, in order."New value: +"Up to 25 slides, in order. Required unless template_id is given."Input schema / properties / template_idAdded value: +{
+ "description": "A saved template id from list_templates. Exports that template with its own theme and slides; theme and slides are then ignored. Errors for it: not_found, template_lookup_failed.",
+ "type": "string"
+}Input schema / properties / theme / descriptionPrevious value: -"Theme id. Only measured themes work; omit to use the default."New value: +"Theme id. Only measured themes work; omit to use the default. A My Theme id (\"custom:...\") from list_themes also works: its base theme's layout with the user's colors."Input schema / requiredRemoved value: -[
- "slides"
-]get_templatelist_templatessave_templateupdate_templateexport_pptxsuggest_deck1 field changedInput schema / properties / layout_idsAdded value: +{
+ "description": "Layout ids the user or you already picked, in slide order. Skips topic matching and slide_count: the preview link is built from exactly these layouts.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}get_layoutget_starter_kitget_themelist_layoutslist_themessuggest_deckDeterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.
Build decks in your own brand, from the AI agent you already use. Then edit them yourself.
Finished, editable PowerPoint (.pptx) decks from a brief and your documents
Agent-Native Google Slides - generate and edit React presentations
Add one secure layer between your agents and this server.
