Skip to main content
Glama

notas

Reads or replaces presenter notes for a slide in a Keynote presentation. Omit text to read existing notes; provide text to overwrite them.

Instructions

Lee las notas del presentador de una diapositiva o, si se da texto, las reemplaza.

Input Schema

NameRequiredDescriptionDefault
textoNo
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.8/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. It does disclose the key behavioral trait that supplying texto mutates/overwrites existing notes ('reemplaza'), which is valuable safety context. It does not say what happens to prior content on empty input, whether the replacement is reversible, or what a read returns when a slide has no notes.

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 well-formed sentence that front-loads the primary (read) behavior and appends the mutation branch. Zero filler.

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?

With three simple parameters, no annotations and no output schema, the description covers the call mechanics adequately. However, it leaves the return value of a read (notes string? empty? null when unset?) and edge cases like empty or very long text unaddressed, which an agent would need for a mutation-capable 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 67%: 'documento' and 'diapositiva' are documented in the schema, and the one undocumented parameter, 'texto', is exactly the one the description explains via the conditional clause. That is meaningful compensation for the coverage gap, though it stops short of stating accepted formatting or length limits for the notes text.

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?

Names the concrete resource ('las notas del presentador de una diapositiva') and both verbs (lee / reemplaza), so an agent knows exactly what the tool touches. It does not need sibling differentiation because no other tool in the list operates on speaker notes, so this is clear but not maximal.

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

Usage Guidelines4/5

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

The conditional 'si se da texto, las reemplaza' explicitly tells the agent which mode applies: omit texto to read, supply it to overwrite. That is a usable when-to-do-what rule, though there are no exclusions or prerequisites (e.g. whether the slide must already exist, whether empty string clears the notes).

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