Pass through full CallToolResult to preserve binary content

[rockfordlhotka]

Summary

• ToolProxyHandler.InvokeAsync now returns Task<CallToolResult> instead of Task<string>, passing the downstream result through unchanged
• ConsumerTools.InvokeTool returns Task<CallToolResult> — the MCP SDK natively supports this return type and passes it straight to the caller
• REST endpoint (ServicesController) returns the full structured CallToolResult JSON

Problem

The previous implementation collapsed all tool results to a single string, silently dropping any non-text content blocks:

// Before — image/audio/embedded-resource blocks became useless placeholders
parts.Add($"[{block.Type ?? "unknown"} content block]");

This meant any downstream MCP server that generates or returns images, audio, or embedded resources would have that content lost in transit.

What flows through now

Content type	Before	After
TextContentBlock	✓ extracted as text	✓ preserved in content[]
ImageContentBlock	✗ [image content block]	✓ base64 + mimeType preserved
AudioContentBlock	✗ [audio content block]	✓ base64 + mimeType preserved
EmbeddedResourceContentBlock	✗ dropped	✓ preserved
IsError = true	thrown as ToolExecutionException (HTTP 400)	returned with isError flag intact

Breaking change

The REST POST /api/services/{name}/tools/{tool}/invoke response shape changes from { "result": "text" } to the full CallToolResult JSON ({ "content": [...], "isError": false }). Callers should check isError in the body rather than relying on HTTP 400 for tool errors.

Test plan

• Build passes (dotnet build)
• Existing tests pass (dotnet test)
• Verify a text-only tool still works end-to-end via MCP client
• Verify an image-returning tool passes the ImageContentBlock through to the caller

🤖 Generated with Claude Code