Creates a new Keynote presentation with a selected theme and saves it immediately as a .key file in the Atril copies folder. Invalid themes return a list of available options.
Crea una presentación nueva con un tema de Keynote y la guarda de inmediato como .key en la carpeta de copias de Atril. Si el tema no existe, el error lista los disponibles.
| Name | Required | Description | Default |
|---|---|---|---|
| alto | No | ||
| tema | No | Basic White | |
| ancho | No | ||
| nombre | No | nombre del archivo, sin extensión |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does disclose the key side effect: the file is written immediately as .key into Atril's backups folder, and invalid themes produce a listing error. However it is silent on overwrite/name-collision behavior, whether the new presentation becomes the active document, and where exactly that folder lives.
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 tight sentences: creation behavior first, error recovery second. No filler. Slightly under-specified rather than verbose, but the structure itself is efficient and front-loaded.
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 four-parameter mutating creation tool with no annotations and no output schema, the description covers purpose, persistence location, and one error case, but omits dimensions semantics and collision handling. Adequate to invoke safely with defaults, not 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 coverage is only 25% (only "nombre" documented, as filename without extension). The description adds meaningful context for tema (must exist, valid values surfaced via error) but says nothing about alto/ancho — their units, defaults, or relationship to slide aspect ratio — leaving half the surface 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?
States a specific verb and resource ("Crea una presentación nueva") plus the theme and immediate .key save, which distinguishes it from opening or reading an existing presentation. It does not explicitly contrast with the sibling crear_con_formato, so differentiation is inferred rather than stated.
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 never says when to use this versus abrir, crear_con_formato, or other creation paths, nor any preconditions. The only conditional mentioned (nonexistent theme -> error listing available themes) is error behavior, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.