JSON output support from tool calls

[rtpa25]

The current tool response is in Markdown format, which is a really nice improvement you guys have made, and I fully understand the rationale behind the move.
However, with Markdown output, it's quite difficult to render frontend components from the tool response (e.g., in Gen UI).

If each tool could accept an outputFormat parameter (with literal values like "md" or "json"), it would solve this issue. This parameter should be optional and default to "md", but if set to "json", the tool must return the raw JSON API response instead of the parsed Markdown output.

I'm open to creating a PR for this as well.

[rtpa25]

I have a draft PR (#412) where I added JSON output for a few tools that required it. Once the core team gives a green light on the approach, I’ll proceed with the remaining tools.

[suptejas]

Agreed on this - especially considering most MCP servers currently return JSON payloads (e.g. Stripe, GitHub). While Markdown is a better format for LLM comprehension, I think having JSON support as a fallback will enable more companies deploying MCP to use Sentry MCP with their existing pipelines.

[dcramer]

What’s the use case here? We’re trying to be explicit about the why of everything we do and we’re also being intentional about the use cases we want to support on our end.

[suptejas]

So on our end, we need this to implement Generative UI for Sentry issues - we’d like the tool call that fetches an issue to return a JSON blob so our React components can render the stack trace, tags, and breadcrumb timeline for the user.

Generative UI in itself is becoming increasingly popular and it's typically achieved by parsing and rendering relevant tool call results directly (in fact, I noticed Seer has a form of generative UI for code diffs for example).

But a more common use case, especially with agentic workflows would be to improve accuracy for follow-on tool calls. In agentic workflows, when one agent calls another, it needs to grab a few key fields (e.g., issueId, trace, release) from the tool call result.

Pulling those directly from JSON is more reliable than extracting key information from a large Markdown answer, plus it likely reduces hallucination risk in follow‑on tool calls.

In terms of the solution, the easiest possible way to achieve this is probably to add another optional key to the tool input schema - like response_type=json|md, with the default being Markdown. We've already opened a draft PR and supporting JSON only requires minimal changes.

[dcramer]

@suptejas my primary concern is outtputing JSON for these kinds of things isnt really anything particularlly different than hitting our API and curating a response, it also complicates the MCP surface area. I recognize that the primary use case we've enabled is agent-based coding (rather than interactive interfaces), but I'm not totally sure we want to expand beyond that today. It effectively would mean a use case we dont totally understand, one that might be competitive with our own products (given the loose definition), and one that we'd be responsible for maintaining.

Any reason to not just build in the native tool call functionality through our integration platform in this kind of case?

[rtpa25]

This hosted MCP server would’ve been super convenient for us to use in our agent (which, to be clear, isn’t competing with Sentry’s AI features—you can check out our work at Dimension).

It would also help us stay up to date with any improvements you make to the project.

But if supporting this isn’t feasible on your end, we totally understand—we’ll self-host instead.