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 / 100000ooxml_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
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.zipfile that ships inside the Part 1 ZIP and containspresetShapeDefinitions.xml.This file is the canonical source for:
adj,adj1,adj2, …) and their default valuesavLst/gdLst/ahLst/pathLstdefinitions 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) usesadj1andadj2as its adjust guide names — not theadjname thatroundRectuses. This is only documented inpresetShapeDefinitions.xml. Querying the MCP with: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")→ returnsadj1(top corner radius, default 16667) andadj2(bottom corner radius, default 0), with the formularadius = ss * adj / 100000ooxml_search("snipRoundRect geometry")→ returns the mixed snip+round corner path definitionThe source file
Inside the Part 1 ZIP you already reference in
data/sources.json: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 namesto theooxml_searchor a newooxml_preset_shapetool — would cover the most common look-up pattern.References
ST_ShapeType) — lists shapes but defers to Annex D for geometryoox-drawingml-adj-names— derived from the same Annex D, maps every shape to its adj guide namesMsBinaryFile/Common/Vml/PPTXShape/OOXMLShapes/— full geometry implementations per shape