160+ finished slide layouts and 41 themes your agent can search, fetch and build a deck from
Scored across 6 tools
Each tool has a clearly distinct role: list_* returns metadata, get_* returns full content, suggest_deck handles deck composition/previews, and get_starter_kit handles assembly. The descriptions even explicitly route ambiguous requests (e.g., list_layouts vs suggest_deck), so misselection is unlikely.
All tool names follow the same snake_case verb_noun pattern: get_layout, get_theme, get_starter_kit, list_layouts, list_themes, suggest_deck. The naming makes the resource and action immediately clear, with no mixed conventions or vague verbs.
Six tools is a well-scoped set for a deck/layout/theme catalog and assembly workflow. Each tool earns its place and there is no redundant overlap or unnecessary bloat.
The surface covers the full workflow: discover layouts/themes, fetch individual resources, generate a composed deck preview, and obtain the starter kit for joining layouts into a final file. There are no obvious dead ends or missing operations for the stated catalog-and-compose purpose.
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 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.
Search or filter the theme catalog. Returns metadata and key colors only, not the full CSS.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | ||
| scheme | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns only metadata and key colors, not the full CSS, which is a meaningful behavioral constraint. It does not mention any side effects or explicitly state it is read-only, but for a search/filter operation this is implicitly safe. The return scope is clearly defined.
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 a single, efficient sentence that front-loads the purpose and immediately clarifies the output scope. There is no wasted wording, and it is well-structured for quick comprehension.
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 no annotations, no output schema, and the parameters are undocumented in the description. The description does not explain valid values for 'mood', whether the tool returns a list or a single theme, or any pagination/sorting behavior. While it states it returns metadata and colors, the lack of parameter guidance and return format details makes it incomplete for an agent to use 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?
Schema description coverage is 0%, meaning the description must explain the parameters. It does not mention 'mood' or 'scheme' at all. The schema has an enum for 'scheme' but no description for 'mood'. The agent has no guidance on what values are valid or how these parameters affect the search. This is a significant gap.
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 action ('Search or filter the theme catalog') and resource (themes), and it differentiates itself from a full-retrieval tool by explicitly noting it returns 'metadata and key colors only, not the full CSS'. This hints at a distinction from a sibling like get_theme, but it does not name that sibling explicitly.
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 implies the tool is for searching/filtering when you need theme metadata or colors, and that it does not return full CSS. This gives context for when to use it, but it does not explicitly state when not to use it or mention alternative tools. The sibling tools list includes get_theme, so a clearer exclusion would strengthen this dimension.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
suggest_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.
Agent-Native Google Slides - generate and edit React presentations
Give your AI agents a design superpower. Generate, edit, and publish publication-grade decks, reports, landing pages, resumes, and marketing visuals directly within your agent workflow. Delivering frontier-level design quality at 3× the speed and 53× lower cost -from conversational prompt to live link or vector PDF in minutes.
Add one secure layer between your agents and this server.
