26.7.2 — Full configuration surface in install snippets (docs/infra only)

What changed

No server code changes — the bump republishes so the refreshed README (install
buttons above the fold, Codex/Windsurf guides, fixed one-click links) reaches the
NuGet package page, Docker/GHCR, and the MCP Registry.

• Every install snippet and one-click deeplink (VS Code / Cursor buttons, Claude
  Desktop/Code, VS Code, VS 2022, Cursor, Windsurf, Cline, Rider, Codex) now
  pre-fills all supported environment variables so users see the full
  configuration surface in the install dialog:
  • GROUPDOCS_MCP_STORAGE_PATH — placeholder documents folder
  • GROUPDOCS_MCP_OUTPUT_PATH — same folder as storage by default
  • GROUPDOCS_LICENSE_PATH — empty by default (evaluation mode)
• Verified in GroupDocs.Mcp.Core's LicenseManager: an empty license path is
  handled identically to an unset one (string.IsNullOrEmpty guard → evaluation
  mode with a log warning; a wrong path only logs; SetLicenseFromPath is wrapped
  in try/catch) — an empty value can never fail the server.

Migration / impact

Drop-in — the server binary is identical apart from the version stamp.

Full Changelog: 26.7.1...26.7.2

26.7.1 — Discoverability & one-click install uplift (docs/infra only)

What changed

Rollout of the org-wide MCP repo improvement plan (piloted on GroupDocs.Conversion.Mcp
26.7.1). No server code changes — the bump ships the new README to the NuGet package page.

• README: badge row (NuGet version/downloads, Docker pulls, MCP Registry, Tests-repo CI,
  MIT), demo placeholder, one-click VS Code / Cursor install buttons, pointer to
  ready-made client configs (Claude Code, VS 2022, Cursor, Windsurf, Cline, Rider), and a
  Licensing section documenting the product's evaluation-mode limits with temporary
  license / purchase links.
• install/config.json + install/generate-install-links.ps1: canonical install config;
  the generator emits install/generated/ (per-client snippets + deeplinks) and rewrites
  the README install-buttons block idempotently. CI drift guard added to
  build_packages.yml (-Check fails the build when generated content is stale).
• Hygiene: SECURITY.md, CONTRIBUTING.md, issue templates, smithery.yaml,
  docker/README.hub.md, llms.txt licensing section, .vscode/mcp.json published-package
  entry, GitHub topics.

Why

AI-agent users find MCP servers through registries, GitHub topics, and READMEs; installers
copy the first snippet they see. One canonical config keeps every rendered snippet correct
permanently, and licensing up front removes the main evaluation-mode surprise.

Migration / impact

Drop-in — the server binary is identical to 26.7.0 apart from the version stamp.

Full Changelog: 26.7.0...26.7.1

26.7.0 — descriptive error handling + Dockerfile MS core fonts

What changed

• Added a shared Tools/ToolError.cs (ToolError.Format(op, file, ex)) that renders engine failures as descriptive text — "<op> failed for '<file>': <ExceptionType>: <message>[ | inner(n): …]" — instead of MCP's opaque "An error occurred invoking '<tool>'". AI agents and integration tests can now read the actual cause.
• GetViewInfo now wraps the engine call in try/catch; on failure it returns text starting with View-info lookup failed for '<file>':.
• RenderPage now catches engine exceptions and returns a CallToolResult with IsError = true and a TextContentBlock starting with Rendering failed for '<file>': (previously an engine throw surfaced as MCP's generic wrapper, hiding the native-deps / font-resolution cause).
• Tool [Description]s now document the failure prefix.
• docker/Dockerfile now installs ttf-mscorefonts-installer (with EULA acceptance via debconf-set-selections + fc-cache refresh) alongside libgdiplus/libfontconfig1. The integration Tests repo already installed MS core fonts on its Linux runners; the server image was missing them, so glyph-heavy rendering (Arial / Times New Roman) could fail font resolution inside the container.
• Version bumped to 26.7.0 (MCP CalVer). Engine GroupDocs.Viewer stays at 26.4.0 (already the latest stable on NuGet); SkiaSharp pin unchanged at 3.119.1.

Why

Both tools historically lacked a try/catch wrapper, so any engine-side failure (missing native deps, unsupported format, font resolution) surfaced as MCP's opaque invocation error — undiagnosable by an AI agent or a CI log. Routing every tool through the shared ToolError.Format matches the contract already used by the Metadata / Conversion MCP servers and lets the integration suite match a stable per-tool prefix.

Migration / impact

Drop-in replacement for 26.5.1. No public-API or wire-name changes; success-path responses are byte-for-byte identical. Only failure responses change shape — they now carry descriptive text (and, for RenderPage, IsError = true).

Full Changelog: 26.5.1...26.7.0

26.5.1 — GetViewInfo JSON response no longer truncated mid-document

What changed

• GetViewInfoTool now returns raw JSON directly instead of routing it through OutputHelper.TruncateText.
• OutputHelper.TruncateText is intended for plain-text output: when the input exceeds McpConfig.MaxOutputCharacters (default 5000), it appends a [Output truncated — showing first X of Y characters. ...] marker on a new line. That marker is non-JSON and breaks any consumer using JsonDocument.Parse / JsonSerializer.Deserialize on the response.
• Affected callers in practice: long documents where the per-page width/height/name list pushes the JSON past 5 KB, plus any client that strict-parses the tool response. Lenient consumers (Claude, Cursor, VS Code Copilot) tolerate the trailing marker, so user-visible AI-agent flows in 26.5.0 are unaffected.

Why

Tools that emit structured JSON should always return valid JSON regardless of size. Truncation should be expressed inside the JSON document (e.g. capped inner array + truncated: true flag) rather than by appending a non-JSON marker line. In practice the response is bounded by API realities (a few KB to ~30 KB), so removing the wrapping is sufficient — no in-document truncation needed today.

Migration / impact

Drop-in replacement for 26.5.0. No public-API or wire-name changes. Tool responses now contain only the JSON document; previous trailing marker line for ~5KB+ responses is gone. Strict-JSON parsers that broke against 26.5.0 work cleanly against 26.5.1.

Full Changelog: 26.5.0...26.5.1

Initial public release of GroupDocs.Viewer MCP Server

What changed

• NuGet package GroupDocs.Viewer.Mcp published with McpServer package type.
• Two MCP tools exposed:
  • RenderPage — render a single document page as a PNG image. Returns a CallToolResult with both a TextContentBlock (saved file path: <source-stem>_page<N>.png) and an ImageContentBlock (PNG bytes inline as image/png). Supports PDF, Word, Excel, PowerPoint, ODT, RTF, HTML, and 170+ more formats; takes optional page (1-based, default 1) and password.
  • GetViewInfo — return file type, page count, and per-page dimensions as JSON. No rendering performed. Optional password for protected documents.
• Installable via dnx GroupDocs.Viewer.Mcp@26.5.0 --yes (.NET 10 SDK required) or dotnet tool install -g.
• Docker image published to ghcr.io/groupdocs-viewer/viewer-net-mcp and docker.io/groupdocs/viewer-net-mcp.
• Environment variables: GROUPDOCS_MCP_STORAGE_PATH, optional GROUPDOCS_MCP_OUTPUT_PATH, GROUPDOCS_LICENSE_PATH.
• Linux native graphics deps wired up: SkiaSharp.NativeAssets.Linux.NoDependencies (3.119.1) is referenced because GroupDocs.Viewer's nuspec declares the SkiaSharp managed and native packages — we pin explicitly so transitive resolution stays deterministic. libgdiplus + libfontconfig1 are installed in the Docker image and the System.Drawing.EnableUnixSupport runtime flag is set because Viewer's Slides, image post-processing, archive-to-Word, mail/Outlook saving, and barcode generation paths still call System.Drawing.Common.

Why

Fourth product MCP server in the GroupDocs MCP framework (after Metadata, Conversion, and Comparison). Exposes
GroupDocs.Viewer for .NET as AI-callable tools for Claude, Cursor,
VS Code / GitHub Copilot, and other MCP-compatible agents.

RenderPage is the first tool in the GroupDocs MCP family to return a CallToolResult directly with an inline ImageContentBlock — AI clients can display the rendered page without a separate fetch.

Migration / impact

First release — no migration required.

Full Changelog: https://github.com/groupdocs-viewer/GroupDocs.Viewer.Mcp/commits/26.5.0