Inspector warning encourages JSON-stringified content when structuredContent is present

[krubenok]

The Inspector UI currently emits a warning No text block matches structured content when a tool returns structuredContent (and the tool has an outputSchema) but none of the content text blocks parse as JSON equal to structuredContent.

This encourages server implementers to make CallToolResult.content a JSON-stringified copy of structuredContent, but the intended usage is that content is model-facing and may be a concise, human-readable summary (semantically equivalent without being a verbatim JSON serialization).

Where this happens:

• client/src/components/ToolResults.tsx: checkContentCompatibility() attempts JSON.parse(textBlock.text) and compares JSON.stringify(parsed) === JSON.stringify(structuredContent).
• Warning message shown when no match is found: No text block matches structured content.

Repro:

1. Define a tool with an outputSchema.
2. Return a result with:
   • structuredContent: a valid object matching outputSchema
   • content: a text summary that is not JSON (e.g. "Temperature is 25C")
3. Inspector shows the warning.

Expected:

• Inspector should not warn just because content is not JSON-identical to structuredContent.
• If we keep any indicator, it should be informational (e.g. "Could not automatically verify semantic equivalence"), or only show a positive signal when a JSON match exists.

Context:

• Related to SEP-2200 / PR #2200 (Clarify tool result content visibility): SEP-2200: Clarify tool result content visibility modelcontextprotocol#2200
• Screenshot of the warning:

Proposed change:

• Remove the negative warning state for this check, or downgrade it to neutral/info.
• Optionally keep a positive hint when a JSON text block exactly matches structuredContent.

[olaservo]

@claude could you implement a change to address this issue?

[claude]

Claude finished @olaservo's task in 3m 7s —— View job

---

Implementation Complete

Todo List

• Read current implementation in ToolResults.tsx
• View the screenshot to understand the warning UI
• Modify checkContentCompatibility to remove negative warning
• Install dependencies
• Build the project to verify changes
• Format code with prettier
• Commit changes locally
• Document solution

Summary

I've successfully implemented a fix for the issue where Inspector was showing a negative warning when structuredContent was present but content wasn't JSON-identical.

Analysis

The issue was in client/src/components/ToolResults.tsx lines 198-209. The UI was showing:

• Blue info box with "✓" when a JSON text block matched structuredContent exactly (positive indicator)
• Yellow warning box with "⚠" when no JSON match was found (negative warning)

The problem: This yellow warning discouraged the correct practice of using human-readable summaries in content. According to the MCP spec (SEP-2200), content should be model-facing and can be a concise summary rather than a JSON-stringified copy of structuredContent.

Changes Made

Modified checkContentCompatibility() function in client/src/components/ToolResults.tsx:

• Changed return type from { isCompatible: boolean; message: string } to { hasMatch: boolean; message: string } | null
• Returns null when no JSON match is found (instead of returning a negative result)
• Only returns a value when a positive match IS found

Updated the UI rendering logic (lines 193-210):

• Only displays the blue info box when compatibilityResult exists AND hasMatch is true
• No warning is shown when content is a human-readable summary (as intended by the spec)
• The positive indicator remains when content does match structuredContent exactly

Result

• ✓ Build completed successfully
• ✓ Code formatted with prettier
• ✓ Changes committed locally with descriptive message
• ✓ References issue Inspector warning encourages JSON-stringified content when structuredContent is present #1089
• 1 file changed: client/src/components/ToolResults.tsx (9 insertions, 20 deletions)

Note on Push Permission

I've committed the changes locally, but encountered a permission issue when attempting to push to the remote repository. The GitHub Actions bot doesn't have write access to push branches.

Next Steps: A maintainer with push access will need to:

1. Pull the branch claude/issue-1089-20260218-1628 from the local commit (hash: 1f84d87)
2. Push it to the remote repository
3. Create a PR using the link below

Or alternatively, the changes can be manually applied by reviewing the commit in the job run artifacts.

---

Branch: claude/issue-1089-20260218-1628