get_slide_info

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

The tool is annotated as readOnlyHint: true, and the description doesn't contradict this. It adds useful context about the returned data—layout, placeholders, shape indices, dimensions in inches, and text preview—which enriches the annotation without overstating side effects. Since readOnlyHint already establishes the non-destructive nature, the description's extra detail on output scope is valuable.

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?

The description is a single, information-dense sentence that front-loads the core purpose ('Get a slide's layout, placeholders and every element') before detailing the specific attributes. It wastes no words and is well-structured for quick consumption by an agent.

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?

The description covers the main output aspects (layout, placeholders, elements, shape index, position/size, text preview) but omits any guidance on the slide_index base (0-based vs 1-based) and leaves presentation_id unexplained. Although an output schema exists and would likely clarify the return structure, the parameter semantics gap remains a missing piece for correct invocation.

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 description coverage is 0%, so the description must compensate, but it does not explain either parameter. slide_index is only implicitly referenced by the tool name and context; the description mentions '0-based index' for shape elements, not for slide_index, leaving ambiguity. presentation_id is completely undiscussed, even though it's optional and nullable, so an agent lacks guidance on when to pass it.

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?

The description clearly states the verb 'Get' and the resource: a slide's layout, placeholders, and every element, with specific details like 0-based shape index, position/size in inches, and text preview. It differentiates from siblings like manage_shape and manage_text by explicitly referencing the shape_index they consume, making its role unmistakable.

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 implies a usage workflow by noting that it returns the shape_index that manage_shape and manage_text take, suggesting it should be used before those editing tools. However, it doesn't explicitly state 'use this when you need to inspect a slide before modification' or name alternative tools like extract_slide_text or get_presentation_info that might also be relevant. The guidance is clear but not fully explicit.

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