[P2] Expose `pptx` in both directions (input requires pandoc >= 3.8.3)

[vivekVells]

Links

• Epic: Tracking: gaps surfaced by an agent-driven document workflow (from #40) #44
• Origin: @pbarone's inbound workflow
• Evidence: docs/audits/2026-08-agent-workflow-audit.md → Finding 2
• Blocked by: the minimum pandoc version issue

Correction to the original issue

This issue previously stated that pandoc cannot read pptx and that pptx should therefore be output-only. That was wrong.

Pandoc 3.8.3, released 2025-12-01, added a native PowerPoint reader:

Add pptx (PowerPoint) as new input format (Anton Antich).
New module Text.Pandoc.Readers.Pptx, exporting readPptx``

The original claim came from testing against a local pandoc 3.7.0.2, which is 14 months old, and reporting the result as a permanent property of pandoc. The conclusion that a python-pptx dependency would be needed is withdrawn.

Problem

pptx is exposed by this project in neither direction, despite pandoc supporting both:

	Pandoc support	Exposed by mcp-pandoc
pptx as output	all supported versions	no
pptx as input	>= 3.8.3	no

Why it is blocked

pyproject.toml declares pandoc>=2.4, which is the PyPI Python library, not the binary. Nothing constrains which pandoc binary a user has. So "mcp-pandoc supports pptx input" currently has no truth value: it depends on a version we neither declare nor check.

Adding pptx input without a version floor would give two users on the same server version different capabilities, with no signal explaining why.

Acceptance criteria

• A minimum pandoc version is declared and checked first, see the blocking issue
• pptx added to output_format, treated as an advanced format requiring output_file
• pptx added to input_format only if the declared minimum is >= 3.8.3, otherwise gated on a detected capability
• Tests both directions, skipped when the local pandoc is too old
• README states the pandoc version required for pptx input

Out of scope

Any non-pandoc pptx library.

[vivekVells]

Split this: output is unblocked, input is not

Found while reviewing #59. This issue is currently blocked as a whole by #54, but only half of it needs to be.

The pptx writer has existed since pandoc 2.0.5 (2017)

It is present in every pandoc 3.x, including the 3.1.3 that Ubuntu 24.04 ships and that our own CI installs.

Confirmed empirically: the CI run on #59 passed while executing a test that writes a pptx via pypandoc, on ubuntu-latest with apt pandoc.

$ pandoc --list-output-formats | grep -x pptx
pptx
$ pandoc --list-input-formats | grep -x pptx      # local pandoc 3.7.0.2
(nothing)

So the two directions have different blockers

	Pandoc requirement	Blocked by	Risk
pptx output (md → pptx)	pandoc 2.0.5, so effectively none	Only our own enum	None
pptx input (pptx → md)	pandoc >= 3.8.3 (2025-12-01)	#54	Absent from Ubuntu LTS and Debian stable

Proposed: do the output half now

Work for pptx output, no version gating needed:

• pptx added to the output_format enum in handle_list_tools
• pptx added to the supported_formats set in handle_call_tool
• pptx added to advanced_formats, since it is binary and needs an output_file
• pptx added back to REFERENCE_DOC_FORMATS (removed in feat: widen reference_doc support to odt and pptx (#52) #59 precisely because the enum did not have it)
• Split the input_format and output_format enums. They share one list today, which is what forces this issue to be all-or-nothing. pptx must appear in output only
• Fixture, conversion matrix in README and CHEATSHEET, tests
• Consider moving odt into advanced_formats in the same change; it is binary and currently fails late with pandoc's "Output to odt only works by using a outputfile"

The input half stays here, blocked by #54, and now has a concrete design in #54's comment: a per-feature minimum checked at point of use rather than a global floor.

One caution on the reader

The pptx reader is roughly 8 months old. Searching for defect reports turned up #9003, #9465, #4181, #6320 — all about the writer or templates, none about the reader. That is weak evidence: it could mean the reader is solid, or that almost nobody has used it. Not verified either way here, since the local pandoc is 3.7.0.2 and has no reader to test. Worth running real decks through pandoc 3.10.1 before exposing it.