FreeDailyPro Tools

pptx_merge

Read-onlyIdempotent

Merge two or more PowerPoint (.pptx) files from freedailypro into one editable presentation (base64), slides in the order the files are given. Each deck keeps its own master, layouts and theme (several masters in one file), so slides keep the look they came with; set useFirstDesign true to put later decks on the first deck's layouts when they match by name. All decks must have the SAME slide size: otherwise it errors (422) naming the decks and their sizes, so fix the size first (in PowerPoint: Design, Slide Size). Comments of the second and later decks are left out. Up to 10 decks and 100 MB in all.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "files": "<files>"
    },
    "name": "pptx_merge"
  }
}

Input Schema

Name	Required	Description	Default
`files`	Yes
`useFirstDesign`	No	Put every later deck on the first deck's layouts. Refused with the reason when they do not match.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses that each deck keeps its own master and theme, that comments from the second and later decks are dropped, that a size mismatch produces a 422 naming the decks, and that limits are 10 decks / 100 MB. No contradiction with annotations — the tool is a pure computation returning base64, consistent with readOnlyHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb, resource, and output format, and nearly every clause carries actionable information. It is a dense run-on paragraph with some noise ("from freedailypro", the parenthetical PowerPoint UI path) that could be trimmed or split for scanability.

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

Completeness5/5

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

With no output schema, the description still states the return form (one editable presentation, base64) and names the failure mode and its fix. For a two-parameter merge tool, an agent has everything needed to call it correctly on the first attempt.

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 only 50% (the top-level `files` array is undocumented), but the description compensates: it explains order significance, the per-deck and total limits, and the full semantics of useFirstDesign including the fallback behavior when layouts do not match by name. It adds real meaning beyond the schema without restating the per-item fields.

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?

Specific verb+resource+output format: merges two or more .pptx files into one editable presentation returned as base64. It is immediately distinguishable from siblings like pptx_split, pptx_organize, or pdf_merge without opening any schema.

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?

Clear operational context: slides follow input order, all decks must share the same slide size or a 422 is returned, and useFirstDesign is opt-in. It never names an alternative sibling (e.g. pptx_organize) or states when not to use it, so it stops short of explicit routing guidance.

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

All FreeDailyPro Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?