Skip to main content
Glama

mover_objeto

Move, resize, or rotate a specific presentation object by type and index to correct slide layout.

Instructions

Mueve, redimensiona y/o gira un objeto, identificado por tipo e índice como en leer_presentacion con detalle.

Input Schema

NameRequiredDescriptionDefault
xNopuntos desde la izquierda (la diapositiva del formato mide 960×540)
yNo
altoNo
tipoYes
anchoNo
indiceYes
rotacionNogrados, en sentido horario
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

C2.9/5.0
Behavior2/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. It implies mutation by saying the tool moves, resizes, or rotates an object, but it does not disclose prerequisites, whether the presentation must be open, how locked objects behave, whether changes are saved, or what the result is.

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?

The description is a single sentence and front-loads the core action. It is efficient with no wasted text, though its terseness leaves important details unstated for a complex 9-parameter mutation tool.

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?

The tool has 9 parameters, no annotations, no output schema, and only 44% schema description coverage. The description gives the basic purpose and object identification but is not complete enough about behavior, prerequisites, parameter semantics, or return effects for reliable invocation.

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

Parameters3/5

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

Schema description coverage is low at 44%, and the description adds some meaning by mapping operations to parameters and by saying the object is identified by tipo and indice as in leer_presentacion con detalle. However, it does not clarify y, alto, ancho, optionality, or constraints, so it only partially compensates for the schema gap.

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 gives specific verbs and resource: "Mueve, redimensiona y/o gira un objeto". It also identifies the object by type and index, referencing leer_presentacion con detalle, so the agent can understand what the tool does, though it does not explicitly contrast with siblings like alinear_objetos or distribuir_objetos.

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 guidance, no exclusions, and no mention of alternatives such as alinear_objetos, distribuir_objetos, or bloquear_objeto. Usage is only implied by the operation names, so the agent must infer the appropriate context.

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