MCP missing Annex D preset shape geometry definitions (presetShapeDefinitions.xml)

[shbernal]

What's missing

The MCP currently indexes the ECMA-376 spec PDFs (Parts 1–4) and the transitional XSDs. It does not index the Annex D electronic addenda — specifically the OfficeOpenXML-DrawingMLGeometries.zip file that ships inside the Part 1 ZIP and contains presetShapeDefinitions.xml.

This file is the canonical source for:

• Per-shape adjust-value guide names (adj, adj1, adj2, …) and their default values
• Per-shape geometry formulas (the full avLst / gdLst / ahLst / pathLst definitions that specify how each preset shape is actually drawn)

Why it matters

The spec prose for preset shapes (§20.1.10.55 ST_ShapeType) just lists enum values and says "see the Annex D addenda" for the actual geometry. That's a dead end for any MCP tool call.

Concrete example that surfaced this gap: round2SameRect (Two Same-Side Round Corner Rectangle) uses adj1 and adj2 as its adjust guide names — not the adj name that roundRect uses. This is only documented in presetShapeDefinitions.xml. Querying the MCP with:

ooxml_search("round2SameRect adj1 adj2 adjust values")

returns nothing relevant. The fix had to be found by searching GitHub for third-party implementations (LibreOffice, ONLYOFFICE) — several wasted search rounds that a properly indexed Annex D would have eliminated.

What indexing this would enable

• ooxml_search("round2SameRect adjust guides") → returns adj1 (top corner radius, default 16667) and adj2 (bottom corner radius, default 0), with the formula radius = ss * adj / 100000
• ooxml_search("snipRoundRect geometry") → returns the mixed snip+round corner path definition
• Any preset-shape question becomes answerable in one tool call instead of a GitHub code-search expedition

The source file

Inside the Part 1 ZIP you already reference in data/sources.json:

https://ecma-international.org/wp-content/uploads/ECMA-376-1_5th_edition_december_2016.zip
  └── OfficeOpenXML-DrawingMLGeometries.zip
        └── presetShapeDefinitions.xml   ← ~190 shape definitions

The file is XML, not a PDF, so it would need a separate ingest path from the existing PDF pipeline. Depending on the implementation approach, even a lightweight option — like adding a curated table of shapeName → adj guide names to the ooxml_search or a new ooxml_preset_shape tool — would cover the most common look-up pattern.

References

• ECMA-376 Part 1 §20.1.10.55 (ST_ShapeType) — lists shapes but defers to Annex D for geometry
• LibreOffice oox-drawingml-adj-names — derived from the same Annex D, maps every shape to its adj guide names
• ONLYOFFICE MsBinaryFile/Common/Vml/PPTXShape/OOXMLShapes/ — full geometry implementations per shape