Skip to main content
Glama

revelar_por_pasos

Creates step-by-step Magic Move reveal animations by inserting partial slide versions so selected objects appear in the specified order.

Instructions

Animación de aparición con Magic Move: los objetos de la diapositiva aparecen en el orden de pasos (cada paso, uno o varios objetos). Se insertan antes versiones parciales de la diapositiva; la original queda como la final. Los índices se toman de leer_presentacion con detalle sobre la diapositiva completa.

Input Schema

NameRequiredDescriptionDefault
pasosYes
duracionNosegundos de cada Magic Move
documentoYesid de la presentación (de listar_presentaciones_abiertas, abrir o crear) o su nombre exacto
diapositivaYesnúmero de diapositiva, empezando en 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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 key non-obvious behavior: it inserts partial copies of the slide into the deck and leaves the original as the final state. That mutation side effect is genuinely valuable. It stops short of noting reversibility, how many slides are created, or what is returned.

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?

Three front-loaded sentences with no filler; the mechanism and the index-sourcing rule each earn their place. Slightly dense, but appropriate for the operation's complexity.

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

Completeness3/5

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

Covers the mechanism, index sourcing and the slide-duplication side effect, which is the core need. With no annotations and no output schema, it should still address what the call returns and how it interacts with pre-existing animations — gaps that matter for a deck-mutating tool.

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?

Schema coverage is 75% and the description adds real meaning for the complex nested `pasos` parameter (each step = one or more objects) and its index provenance. `documento`, `diapositiva` and `duracion` are already documented in the schema, so nothing critical is missing.

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 (animate/reveal) and mechanism: objects appear in `pasos` order via Magic Move, with partial slide versions inserted before the original. This is clear enough to distinguish from generic animation, though it never names the close siblings `animar_cambio` or `revelar_series` to disambiguate.

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?

It gives one useful precondition — indices must come from `leer_presentacion` with detail on the full slide — but never says when to choose this over `animar_cambio` (transition animation) or `revelar_series` (chart-series reveal). Usage is implied rather than stated.

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