Builds a new Word document from XML matching Kookerella.FsWordDsl's own embedded schema (Xml.xsd) and saves it to disk - the inverse of generate_xml. The natural target for a caller that already produces data as XML (e.g. an XSLT pipeline generating a report) and wants to reach Word without learning the OOXML schema, this library's own F#/C# API, or needing .NET installed at all - like generate_xml, the .NET work happens inside this server, so any language can call it directly, and a human with no MCP client at all can get the same result via fsworddsl-mcp build from a plain shell. Covers the same section/paragraph-level feature set generate_xml does; unlike create_document, this isn't limited to plain paragraph text - named styles, tables, images, and every other modeled feature can be expressed in the XML.

Creates a new Word document (.docx) from a simple list of paragraph texts and saves it to disk. Each string becomes one plain paragraph, in order - no formatting, styles, tables, or images in this version. Does not support run styling, tables, images, headers/footers, or track changes - reference the Kookerella.FsWordDsl library directly for those.

Reads an existing Word document and returns a self-contained F# script (using Kookerella.FsWordDsl) that rebuilds an equivalent file when run via dotnet fsi. Useful for explaining how a file is structured, or as a starting point for a caller who wants the library's full feature set (named styles, tables, images, headers/footers, comments, track changes, content controls, etc.) beyond what create_document exposes.

Returns the raw JSON Schema (Json.schema.json) that generate_json's output and create_document_from_json's input both conform to. Meant for a caller authoring JSON by hand or by a generation script who wants real schema validation/autocomplete in their own editor or pipeline, rather than reverse-engineering the shape from a generate_json example. This schema isn't validated against at runtime by the core library itself the way Xml.xsd is (JSON Schema has no .NET-built-in equivalent to System.Xml.Schema, so wiring that up would mean adding a runtime dependency - JsonSchema.Net - to every consumer of the core library just for this) - it's bundled here, in the Mcp tool specifically, purely to hand back on request.

Reads an existing Word document and returns a self-contained C# file (using Kookerella.CsWordDsl) that rebuilds an equivalent file when run via dotnet run <file>.cs (.NET 10's file-based apps feature - no .csproj needed). The C# equivalent of generate_fsharp_script, for a caller who wants pasteable/ runnable C# rather than F# - useful for explaining how a file is structured, or as a starting point for the wrapper's fluent API (named styles, tables, images, headers/footers, comments, track changes, content controls, protection, etc. - Kookerella.CsWordDsl covers the same feature set as generate_fsharp_script's own Kookerella.FsWordDsl) beyond what create_document exposes.

Reads an existing Word document and returns it as JSON. The JSON-side equivalent of generate_xml, for a caller whose tooling speaks JSON rather than XML - same use cases (inspect, transform, or archive a document's structure without any F#/C# source, or any .NET runtime at all, on the caller's side) and the same section/paragraph-level feature set. Usable directly from Python, JavaScript, or any other language, and a human with no MCP client at all can get the same result via fsworddsl-mcp convert <file> --lang json from a plain shell. Unlike generate_xml, there's no runtime JSON Schema validation built into the core library itself (see generate_json_schema's own doc string for why) - but generate_json_schema still returns the documented shape this produces.

Reads an existing Word document and returns it as XML, validated against Kookerella.FsWordDsl's own embedded schema (Xml.xsd). A plain-data alternative to generate_fsharp_script/generate_csharp_script for a caller who wants to inspect, transform (e.g. via XSLT), or archive a document's structure without any F#/C# source involved - and without any .NET runtime on the caller's side either: the .NET work happens inside this server, so Python, JavaScript, or any other language can call this tool directly, and a human with no MCP client at all can get the same result via fsworddsl-mcp convert <file> --lang xml from a plain shell. Unlike those two, this returns data, not a runnable script, so there is no output-filename parameter to control what a rebuild saves as. Covers the same section/paragraph-level feature set generate_fsharp_script does.

Reads an existing Word document (.docx/.docm) and returns its paragraphs as a JSON array of plain strings, one per paragraph, matching create_document's own input convention. Features outside the plain-paragraph model (run styling, tables, images, headers/footers, comments, track changes, content controls, etc.) are not included in this output - see MAPPING.md in the main library repo for the full list of what round-trips. Table content and non-paragraph blocks are skipped entirely.

Returns the raw XSD (Xml.xsd) that generate_xml's output and create_document_from_xml's input both conform to. Meant for a caller authoring XML by hand or by transform (e.g. an XSLT stylesheet) who wants real schema validation/autocomplete in their own editor or pipeline, rather than reverse- engineering the shape from a generate_xml example.

Builds a new Word document from JSON matching the shape generate_json produces (see the main library repo's Json.schema.json) and saves it to disk - the inverse of generate_json. The JSON-side equivalent of create_document_from_xml, for a caller that already produces data as JSON and wants to reach Word without learning the OOXML schema, this library's own F#/C# API, or needing .NET installed at all - the .NET work happens inside this server, so any language can call it directly, and a human with no MCP client at all can get the same result via fsworddsl-mcp build from a plain shell. Covers the same section/paragraph-level feature set generate_json does; unlike create_document, this isn't limited to plain paragraph text - named styles, tables, images, and every other modeled feature can be expressed in the JSON.