Skip to main content
Glama
DEvauthentic

mcp-carousel-engine

by DEvauthentic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

MCP Carousel Engine

License: MIT Node.js Version MCP Specification Format Engine

The Professional Model Context Protocol (MCP) Server for High-End 4:5 Vertical Social Carousels.
Designed and engineered by Said KOMI (Ingénieur Réseaux et Système).

Aperçu Visuel • Règles d'Or • Installation • Outils MCP • Primitives React • Exemples

[▸] Aperçu Visuel / Showcase

Voici un aperçu d'un carrousel réel de 6 slides produit avec mcp-carousel-engine sur le sujet « Amazon VPC Architecture » (Thème Orange AWS & Vert Émeraude, Auteur : Said KOMI) :

Related MCP server: Remotion MCP App

[▸] Pourquoi ce Serveur MCP ?

Les carrousels sur les réseaux professionnels (LinkedIn, Facebook, Instagram) souffrent souvent de trois problèmes majeurs générés par les outils d'IA traditionnels :

  1. Le "Template AI Slop" : Des mises en page génériques, plates, saturées d'émojis enfantins et sans identité visuelle.

  2. Le Débordement & Décalage CSS : L'utilisation de librairies comme html2canvas qui cassent les masques de texte dégradés, tronquent les cartes et produisent des espaces blancs disproportionnés.

  3. Le Cadrage Défectueux des Photos : Des avatars coupés au niveau du front ou des cheveux en haut de carte.

mcp-carousel-engine résout mathématiquement ces problèmes. Il fournit aux agents IA (OpenCode, Claude Code, Cursor, Codex, Antigravity) une suite de primitives de design modulaires et un moteur de compilation Chromium natif pour générer des visuels d'une netteté vectorielle absolue.

[▸] Les 5 Règles d'Or du Système

N°

Règle

Spécification Technique

Rationale

01

Ratio 4:5 Vertical Strict

Canvas fixé à $1080\text{ px} \times 1350\text{ px}$ avec overflow: hidden et box-sizing: border-box.

Format d'engagement maximal sur mobile, élimine tout défilement parasite.

02

Zéro Émoji (Strict Policy)

Interdiction totale des émojis. Utilisation exclusive de glyphes (::, //, [+], [✓], ->).

Confère un look d'ingénierie moderne, sobre et hautement professionnel.

03

Éclairage 3D Volumétrique

Dégradés radiaux multi-points (radial-gradient(circle at 35% 30%, ...)) avec halo coloré diffus.

Crée une illusion de profondeur tridimensionnelle sans nécessiter de moteur WebGL lourd.

04

Cadrage Zéro Coupure de l'Avatar

Ancrage optique calibré (object-position: center 8%) dans un médaillon à double anneau dégradé.

Garantit que le visage, le front et les cheveux de l'auteur sont toujours parfaitement visibles.

05

Rendu Chromium Natif

Compilation headless via Chromium (Remotion Stills) à échelle 1:1.

Élimine à 100% les décalages de rendu et les pertes de calques CSS.

[▸] Installation & Configuration

1. Cloner et compiler le serveur

git clone https://github.com/DEvauthentic/mcp-carousel-engine.git
cd mcp-carousel-engine
npm install
npm run build

2. Déclarer dans vos Agents IA

Pour Claude Desktop (claude_desktop_config.json) :

{
  "mcpServers": {
    "carousel-engine": {
      "command": "node",
      "args": ["/chemin/absolu/vers/mcp-carousel-engine/dist/index.js"]
    }
  }
}

Pour OpenCode / Antigravity / Cursor (mcp_config.json ou .cursor/mcp.json) :

{
  "mcpServers": {
    "carousel-engine": {
      "command": "node",
      "args": ["c:/VEILLE TECHNOLOGIQUE/laboratoires/agentic-google/mcp-carousel-engine/dist/index.js"]
    }
  }
}

[▸] Outils MCP Exposés

1. get_design_rules

Retourne à l'agent l'ensemble des règles typographiques, de ratio et de contraste pour cadrer sa génération de contenu.

2. list_creative_archetypes

Fournit un catalogue d'archétypes de design prêts à être remixés :

  • neo-geometric-dark : Le style signature Said KOMI (Fond noir #000000, cartes blanches contrastées, sphères 3D orange/émeraude, capsules dégradées).

  • frosted-glass-blueprint : Cartes translucides en verre dépoli (backdrop-filter: blur(40px)), accents cyan et repères laser.

  • minimal-luxury-monolith : Fond craie #F4F3EF, carte monolithique noir obsidienne et pierre d'ambre 3D.

3. list_design_primitives

Liste l'ensemble des composants React modulaires utilisables pour composer des slides personnalisées.

4. render_carousel_project

Prend un fichier ou objet JSON décrivant les slides et génère :

  • Les images PNG haute définition ($1080 \times 1350\text{ px}$).

  • Le visualiseur web interactif index.html.

[▸] Boîte à Outils de Primitives React

Les agents peuvent assembler ces composants en toute liberté :

import { 
  SlideCanvas, 
  WireframeGrid, 
  ShadedOrb3D, 
  LayeredCard, 
  PillBadge, 
  GradientMaskText, 
  ProfileMedal, 
  CarouselDots 
} from 'mcp-carousel-engine/primitives';

// Exemple de Slide 01 (Hook & Titre Dégradé)
export const Slide01 = () => (
  <SlideCanvas backgroundColor="#000000">
    <WireframeGrid hLines={[220, 1120]} vLines={[200, 880]} />
    <ShadedOrb3D size={140} colorTheme="orange" top={310} left={350} />
    
    <div style={{ zIndex: 3, marginTop: 'auto', marginBottom: 'auto' }}>
      <GradientMaskText text="amazon" fontSize={130} />
      <div style={{ fontSize: 180, fontWeight: 900, color: '#FFFFFF', lineHeight: 0.88 }}>vpc</div>
      <PillBadge text="la forteresse du cloud" />
    </div>

    <CarouselDots activeIndex={0} total={6} />
  </SlideCanvas>
);

[▸] Exemples Prêts à l'Emploi

Deux exemples complets et testés sont inclus dans le dossier examples/ :

  1. examples/aws-vpc-carousel.json — Carrousel d'architecture réseau AWS VPC (6 slides).

  2. examples/docker-networking-carousel.json — Deep dive sur les drivers réseau Docker (Bridge, Host, Macvlan, Overlay).

[▸] Exemple de Prompt pour votre Agent IA

Une fois le serveur MCP connecté, il vous suffit de demander à votre agent :

"Crée un carrousel de 6 slides sur Kubernetes Networking avec le serveur MCP carousel-engine. Thème cyan, auteur Said KOMI (Ingénieur Réseaux & Système)."

L'agent va :

  1. Consulter get_design_rules et list_creative_archetypes.

  2. Rédiger les textes percutants selon la structure de storytelling validée.

  3. Appeler render_carousel_project.

  4. Livrer les fichiers PNG $1080 \times 1350\text{ px}$ et le visualiseur web interactif.

[▸] Auteur & Licence

  • Concepteur & Architecte : Said KOMI

  • Rôle : Ingénieur Réseaux et Système

  • Licence : MIT License

Available Tools

4 tools
get_design_rulesA

Returns the mandatory design rules, aspect ratios (4:5 vertical 1080x1350), zero-emoji policy, and typography standards for creating world-class carousels.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the full burden, and it does disclose the substance of what is returned (mandatory rules, 4:5 / 1080x1350 aspect ratios, zero-emoji policy, typography standards) plus the fact that these rules are mandatory rather than advisory. It is silent on return format/structure, but for a zero-parameter read-only fetch this is a strong disclosure.

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

Conciseness4/5

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

One sentence, front-loaded with the verb and resource, with the enumerated contents following immediately. The only padding is the mildly promotional 'world-class carousels', which is minor waste but not enough to hurt structure.

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

Completeness4/5

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

For a parameterless tool with no output schema, the description needs to convey the returned content to be useful, and it does via the enumerated rule categories. The remaining gap is that it does not describe the shape/format of the returned rules, but nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

The tool takes zero parameters, which is the baseline-4 case; there is no parameter semantics to document or omit. The description correctly implies a single unfiltered fetch with no arguments.

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

Purpose5/5

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

States a specific verb ('Returns') and resource ('mandatory design rules') and then enumerates the actual content (aspect ratios, zero-emoji policy, typography standards), so an agent knows exactly what it gets back. It is clearly distinguishable from the list_* and render_* siblings because it describes a fixed standards payload rather than enumerating options or producing output.

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 phrase 'for creating world-class carousels' implies the context of use (fetch these rules before building a carousel), but the description never states when to call this versus list_design_primitives or the other siblings, and offers no exclusions or prerequisites. Usage is only implied, which matches a 3.

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

list_creative_archetypesA

Returns a catalogue of creative layout archetypes (Dark Neo-Geometric, Frosted Glass Blueprints, Minimal Luxury Monolith) with color palettes and layout suggestions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It does describe the return payload (archetype names, color palettes, layout suggestions), which is useful behavioral context, but says nothing about read-only safety, permissions, or cost — acceptable gaps only because this is a zero-parameter catalogue lookup.

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?

A single front-loaded sentence that names the resource first and then the contents, with no filler. Every clause earns its place.

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

Completeness4/5

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

For a zero-param, no-output-schema catalogue tool, stating what the payload contains is sufficient. The only real omission is any routing guidance relative to sibling design tools.

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

Parameters4/5

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

The tool takes zero parameters, so there are no parameter semantics to convey; the baseline for an argument-less tool is 4.

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?

States a specific verb ('Returns') and resource (a catalogue of creative layout archetypes), and concretizes it with three named examples plus the payload contents. It does not, however, distinguish itself from the sibling list_design_primitives or get_design_rules, which an agent could easily confuse it with.

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

Usage Guidelines2/5

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

There is no when-to-use instruction, no condition, and no mention of alternatives among the sibling tools. The agent must infer usage purely from the fact that it returns a catalogue.

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

list_design_primitivesA

Lists all available React design primitives (SlideCanvas, WireframeGrid, ShadedOrb3D, LayeredCard, PillBadge, GradientMaskText, ProfileMedal, CarouselDots) with their props.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Lists' correctly implies a safe read-only operation, and 'with their props' hints at return content beyond the names, but there is no mention of output shape, formatting, or any auth/limits context.

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

Conciseness4/5

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

A single front-loaded sentence that states the action first and the enumerated contents second. The parenthetical name list is long but directly useful for selection; only minor trimming is possible.

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

Completeness4/5

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

For a parameterless listing tool with no output schema, the description covers what is listed and mentions that props accompany each item, which is adequate for calling it correctly. It stops short of describing the returned prop structure, but nothing else is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing about parameters for the description to clarify or obscure.

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

Purpose5/5

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

States a specific verb ('Lists') and resource ('React design primitives') and enumerates the exact set returned, so an agent knows precisely what comes back. It is clearly distinguishable from the parallel sibling list_creative_archetypes and from get_design_rules.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus get_design_rules, list_creative_archetypes, or render_carousel_project, nor any prerequisite or sequencing guidance. Usage is only implied by the name and the enumeration.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedget_design_rules
    • First observedlist_creative_archetypes
    • First observedlist_design_primitives
    • First observedrender_carousel_project
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: retrieving design rules, listing archetypes, listing primitives, and rendering the final project. There is no overlap between any of the four purposes, so an agent cannot easily misselect.

Naming Consistency5/5

All names follow a consistent verb_noun snake_case pattern (get_design_rules, list_creative_archetypes, list_design_primitives, render_carousel_project). The convention is predictable throughout.

Tool Count4/5

Four tools is on the lean side but coherent for a focused carousel generator: three are read-only reference lookups and one produces output. It is well-scoped, though slightly thin for a full authoring pipeline.

Completeness4/5

The surface covers the key lifecycle of discovery (rules, archetypes, primitives) plus final rendering, with no obvious dead ends. Minor gaps like validation, single-slide preview, or export-format options exist but are workable.

Resources

Related MCP Connectors

Related MCP Servers