Skip to main content
Glama
MoonTzai

FolderBridge MCP

by MoonTzai

Inspect PPTX OOXML and SmartArt

pptx_inspect
Read-only

Inspect PPTX files safely by parsing ZIP/XML to extract slide text, diagram mappings, and connection diagnostics without executing macros or embedded code.

Instructions

Safely inspect a PPTX inside the selected workspace using Python standard-library ZIP/XML parsing. Returns slide text, diagram-to-slide mappings, dgm:pt points, dgm:cxn connections, and orphan/duplicate diagnostics. Does not execute macros, embedded objects, or workspace code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
page_endNo
page_startNo
workspace_idNoRequired when server_info lists multiple workspaces.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.25

TDQS

A3.6/5.0
Behavior5/5

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

The description explicitly discloses safety-relevant behavior: it does not execute macros, embedded objects, or workspace code. This goes beyond the readOnly/destructive annotations and reassures the agent about side effects.

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?

The description is compact and well structured: a safety-and-method sentence, a returns list, and a non-execution guarantee. Every sentence adds meaningful information without redundancy.

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 no output schema, the return-value list is helpful, and the safety behavior is clear. However, the description omits parameter semantics and does not fully explain how page_start/page_end affect inspection, leaving noticeable gaps for a four-parameter tool.

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

Parameters1/5

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

Schema coverage is only 25% and the description does not explain path, page_start, or page_end. Only workspace_id is described in the schema; the description adds no parameter-level clarification, leaving the agent to guess meanings and ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('inspect a PPTX') and resource, and lists concrete outputs ('slide text, diagram-to-slide mappings, dgm:pt points...'). It is clearly differentiated from the sibling tools by its OOXML/SmartArt focus.

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?

No guidance is given on when to use this tool versus alternatives such as file_info or image_open. It implies use for PPTX inspection but does not explicitly state selection criteria or exclusions.

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