Skip to main content
Glama

Carousel Theme Kit

carousels_kit
Idempotent

Save or apply a theme, brand theme, or named slide template. Themes rewrite fonts, colors, overlay, and asset: logos. Never persist signed URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
nameNo
scopeNo
themeIdNo
projectIdYesUUID string.
slideIndexNo
workspaceIdNo
idempotencyKeyYes
savedTemplateIdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kitNo
nameNo
frameNo
styleNo
localeNo
slidesNo
can_undoNo
platformNo
revisionNo
warningsNo
templatesNo
project_idNo
next_actionsNo
mutationReceiptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds real behavioral context beyond the annotations: applying themes rewrites fonts, colors, overlays, and asset logos, and 'Never persist signed URLs' is a concrete constraint. The main gap is that delete_theme and delete_template operations are not disclosed, though this does not contradict the readOnly or idempotent hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the main action and containing no filler. The side-effect warning and signed-URL constraint each earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a 7-value op enum, 9 parameters, and delete operations, three sentences are not enough. An agent cannot determine which parameters are required per operation or how scope, workspaceId, and slideIndex interact; the output schema covers return shape, but the operation-selection semantics remain under-documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 11% schema description coverage, the description needed to explain op, themeId, savedTemplateId, scope, and slideIndex, but it only adds general context about what themes rewrite. It does not clarify per-operation parameter requirements or the difference between project and brand scope.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb-resource pair ('Save or apply a theme, brand theme, or named slide template') and adds detail about what themes do ('rewrite fonts, colors, overlay, and asset:<id> logos'). It does not explicitly distinguish from sibling apply/list tools, and it omits the delete operations visible in the op enum, so it is not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case by saying the tool saves/applies themes, and the op enum provides sub-operations. However, it never states when to prefer this tool over siblings such as captions_themes_list, story_kits_apply, or series_apply, nor does it give any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources