office_docs_mcp

Overview Schema Source Related Servers Discussions Admin

ppt_search

Search PowerPoint files for specific text across slides, shapes, tables, and notes. Provide a file path and query to retrieve matching results.

Instructions

Search for a text query across PowerPoint slides, shapes, tables, and notes.

Args:
    file_path: Path to the PowerPoint file (.pptx).
    query: Text to search for.
    case_sensitive: Whether matching is case-sensitive (default: False).
    max_results: Maximum results to return (default: 50).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes
`file_path`	Yes
`max_results`	No
`case_sensitive`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 27, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description must carry behavioral context. It discloses the search scope (slides, shapes, tables, notes) and the optional case-sensitivity/result-cap behavior. It does not explicitly state that the file is unmodified, but 'Search' strongly implies a read-only operation.

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 front-loaded with a one-sentence purpose summary and then a tight Args block. Every sentence earns its place, and there is no fluff or redundant explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with an output schema present, the description plus the input schema covers all parameters and the search scope sufficiently. It is mildly incomplete only in not explicitly stating that the operation does not modify the file, but this is strongly implied by 'Search'.

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 description coverage is 0%, so the description must compensate. It does: file_path is defined as a .pptx path, query as text to search for, and case_sensitive/max_results have clear meanings and defaults. It stops short of detailing match semantics (e.g., substring vs. regex), so it is not a perfect 5.

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 verb ('Search') and resource ('PowerPoint slides, shapes, tables, and notes'), making the tool's purpose immediately clear. This also separates it from read-only tools like ppt_read_slide and from word/excel search tools by naming the PPT content scope.

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 explicit guidance about when to use this tool versus alternatives such as ppt_get_outline, ppt_read_notes, or word_search. The only implied usage is that 'Search' is the right operation for locating text, but no exclusions or sibling comparisons are provided.

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