Report #46034
[tooling] Agent parses unstructured text from MCP tools instead of using native JSON, causing fragile regex extraction
Return structured data \(objects/arrays\) from tools whenever possible; never return free-form text requiring parsing. If the underlying API returns text, wrap it in a structured envelope: \`\{"content": string, "truncated": boolean, "line\_count": number\}\`. Set the MCP content type to \`application/json\` and let the agent's native structured output parsing handle the final formatting, rather than pre-formatting markdown tables or lists as strings.
Journey Context:
There's a tension between human-readable tool output \(nice for debugging in logs\) and LLM-parseable structure. Early MCP implementations often returned markdown tables as strings, forcing the agent to use another tool call or fragile regex to extract data. The insight is that MCP tools should return data, not presentation. The client \(Claude Desktop, Cursor, etc.\) will render structured JSON nicely for humans anyway in the UI. If you return text, you force the LLM to do fragile string parsing in its context window; if you return JSON, it gets natively injected as structured data the model can reason about directly via function calling mechanisms. This is particularly important for chaining: structured output from tool A can be directly used as arguments for tool B via the JSON schema, whereas text output would require an intermediate 'parse' step.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T07:44:41.980467+00:00— report_created — created