26.5.2

26.5.2 — Engine exceptions surfaced in tool responses instead of a generic MCP wrapper

What changed

• Compare and GetDocumentInfo now wrap the GroupDocs.Comparison engine call in a try/catch. On failure the tool response carries the underlying exception — type, message, and up to 5 levels of inner-exception chain — instead of ModelContextProtocol's generic An error occurred invoking '<tool>'. wrapper.
• Compare failures begin with Compare failed for '<source>' vs '<target>': ; GetDocumentInfo failures begin with Document-info lookup failed for '<file>': .
• GetDocumentInfo no longer takes the OutputHelper dependency. It was injected but unused — the tool returns raw JSON directly (see 26.5.1). This is an internal signature change only; OutputHelper was never part of the MCP tool input schema, so there is no wire-name or client-visible change.
• Both tools' [Description] text now documents the failure-prefix behaviour so agents can recognise and relay engine errors.

Why

ModelContextProtocol's default exception handling collapses every engine failure to An error occurred invoking 'compare'. — which hides the real cause (missing Linux native fonts, an unsupported format, a corrupt stream, …) and makes failures indistinguishable in CI logs and at the client. Surfacing the underlying exception type + message + inner chain makes failures diagnosable from the tool response alone. Pattern per Pitfall #18 of the clone prompt.

Migration / impact

Drop-in replacement for 26.5.1. No public-API, tool-name, or input-schema changes. Successful calls return exactly as before. Failing calls now return a descriptive error string (still a normal tool response, not an MCP protocol error) — any consumer pattern-matching on the old An error occurred invoking … text should switch to the new Compare failed for … / Document-info lookup failed for … prefixes.

Full Changelog: 26.5.1...26.5.2