Kitty/inline terminal chart visualisation

[tallpsmith]

The Why

During production triage in the terminal, "pictures tell a thousand words." If the user's terminal supports inline image rendering (Kitty graphics protocol, iTerm2 inline images, Sixel), pmmcp could render charts directly in Claude's output — no browser switch needed, no context loss.

Depends on: #10 (establishes the visualisation architecture and fallback cascade)

---

Context from #10 Design

The #10 design brainstorm identified inline terminal charts as a future option (priority 3, after Grafana and HTML fallback). The primary question is Linux terminal support — the target audience is predominantly Red Hat users.

---

Research Needed

Before committing to an approach, research is needed on:

Terminal Protocol Support

• Kitty graphics protocol — well-supported on Kitty terminal itself, but what about common Linux terminal emulators (GNOME Terminal, Konsole, Alacritty, tmux, screen)?
• Sixel — broader support across terminals but lower quality. Works in xterm, mlterm, some others.
• iTerm2 inline images — macOS only, not useful for the Red Hat audience
• Which protocol(s) do Red Hat / enterprise Linux shops actually use?

Chart Rendering

• What Python libraries can render charts to PNG/SVG in-memory without a display server (headless)?
  • matplotlib (heavy but capable)
  • plotext (terminal-native ASCII/braille charts — no image protocol needed)
  • sparklines / asciichartpy (very lightweight, text-only)
• Could we use Grafana's image renderer as the chart source instead of generating our own? (see rich reports issue)

MCP Transport Considerations

• MCP uses JSON-RPC over stdio — can image data be embedded in tool responses?
• FastMCP supports ImageContent blocks — would Claude Code / other MCP clients render these inline?
• Or does the image need to be written to a file and the path returned?

---

Possible Approaches

1. ASCII/braille charts — plotext or similar. Works in ANY terminal. Low fidelity but zero dependencies on terminal capabilities. Could be v1.
2. Kitty graphics protocol — high fidelity PNGs rendered inline. Requires Kitty or compatible terminal. Detect capability at runtime, fall back to ASCII.
3. Grafana-sourced images — use get_panel_image from mcp-grafana, write to temp file, return path. Terminal-agnostic but requires Grafana.

Recommendation from Brainstorm

Start with ASCII/braille charts (approach 1) if implementation is trivial — it's terminal-agnostic and adds value immediately. Defer Kitty protocol support until we confirm the target audience's terminal landscape.

---

Open Questions

• What terminals do the Red Hat target users actually run?
• Is plotext (or similar) acceptable as a dependency, or is zero-dependency a hard constraint?
• Would ASCII sparklines in tool output be "good enough" vs full chart images?
• How does Claude Code handle ImageContent in MCP tool responses today?