ppt-mcp

ppt_set_conversion_target

Persist the conversion target for a route workflow by recording the PDF path and page-range decision, and confirm the selected pages before proceeding with conversion.

Instructions

Write pdf_path and page range decisions into a locked route workflow.

This is step 2 of the high-level guided flow. Use it to persist conversion target state so weaker models do not have to remember page ranges from chat history. pdf_path must be a real local PDF path explicitly provided by the user. Do not treat the page scope as complete until page_range_confirmed=true is explicitly written for the currently selected pages.

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": {
      "route_workflow_id": "<route_workflow_id>"
    },
    "name": "ppt_set_conversion_target"
  }
}

Input Schema

Name	Required	Description	Default
`page_end`	No
`pdf_path`	No
`page_start`	No
`route_workflow_id`	Yes
`page_range_decision`	No
`page_range_confirmed`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 2, 2026

TDQS

A4.2/5.0

Behavior4/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 discloses persistence into a locked workflow, requires explicit user-provided pdf_path, and warns that page scope is not complete until page_range_confirmed=true is written. It does not discuss lock semantics or overwrite behavior, but the critical behavioral constraints are present.

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 four concise sentences, front-loaded with the primary purpose, then context, then two critical operational warnings. Every sentence earns its place; there is no fluff or redundant restating of the tool name.

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?

Given the tool has 6 parameters, no annotations, and an output schema (not shown), the description provides good context: its place in the flow, persistence rationale, and confirmation semantics. It could further explain page_start/page_end vs page_range_decision relationships, but it suffices for an agent to select and invoke the tool correctly in most guided-flow scenarios.

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

Parameters3/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 adds meaning for pdf_path (must be real local PDF path) and page_range_confirmed (must be explicitly true before scope is complete), and mentions 'page range decisions' for page_range_decision. However, page_start/page_end interaction and route_workflow_id semantics are left implicit, so compensation is only partial.

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 opens with a specific verb+resource statement: 'Write pdf_path and page range decisions into a locked route workflow.' It clearly identifies the tool's purpose as persisting conversion target state and explicitly labels it as 'step 2' of a guided flow, distinguishing it from sibling tools like ppt_set_route_options and ppt_convert_pdf.

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?

Provides clear contextual guidance: it is step 2 of a guided flow, used to persist state so weaker models don't need to remember page ranges. It also sets a firm prerequisite that pdf_path must be a real local PDF path explicitly provided by the user. It does not name alternatives or state when not to use it, but the sequential flow context is strong.

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

Deploy Server