GSoC 2026 with HoloViz: My Journey Building a Live Visualization Layer for AI Using Panel and MCP Server

I got selected for Google Summer of Code 2026 with NumFOCUS, contributing to the HoloViz ecosystem. My project is panel-live-server, and this blog is where I’ll document everything — the wins, the walls I hit, and what I learned along the way.

Community Bonding Period (May 1–25)

The community bonding period is supposed to be about getting comfortable before coding starts. For me it was more like, I couldn’t wait, so I just started.

The first thing I did was sit down with my mentor, understand the project properly, and figure out what direction we were heading. That first meeting helped a lot. Instead of just reading code in isolation, I had context for why things were built the way they were.

Then I started digging into the codebase and quickly found things I wanted to fix.

The CSP problem: One of the first real issues I tackled was a Content Security Policy conflict. In some MCP clients like VS Code and Cursor, the inline visualization panel was breaking because the CSP headers weren’t aligned between the MCP App resource and what the browser expected. I traced it through the FastMCP ResourceCSP configuration, figured out which domains needed to be in frame-src and resource-src, and got it working so visualizations render inline in the chat without any iframe blocking. That felt good to ship.

Renaming for clarity: I also landed a small but meaningful cleanup — the method parameter values were named “jupyter” and “panel”, which was confusing because neither name described what the method actually did. Renamed them to “inline” and “server” which is much clearer. Small change, but this kind of thing matters when other people are reading and using the code.

Latency work: This is where I spent most of my time. A single show() call was running the snippet’s Python code three times — once to validate in the MCP server, once again during storage on the Panel server, and once to actually render. Two of those three executions produced nothing the user ever sees.

I traced the full pipeline from server.py → client.py → endpoints.py → database.py, found the redundant middle execution, and added a skip_validation flag. When the MCP server has already validated the code before sending it, the storage layer now skips the re-run entirely. I also removed unnecessary Panel widget-state precomputation on the render side (embed=False instead of embed=True with max_states=500). The difference in VS Code and Cursor is noticeable.

Claude Desktop is a separate challenge — its Electron WebView sandbox blocks localhost iframes and fetch() calls at the CSP level. I tried an async fetch approach to deliver the rendered HTML without blocking the tool response, but Claude Desktop’s sandbox blocks that too. Still working on it.

What I learned about MCP: Before this project I had a surface-level understanding of the Model Context Protocol. Now I’ve been deep in it — ResourceCSP, App resources, tool result payloads, how MCP Apps communicate with the host client. It’s a young protocol and the tooling is still evolving, which means there’s real room to push things forward.

What’s coming

Coding officially starts after May 25. The plan is to keep pushing on latency, figure out a proper Claude Desktop delivery path, and then move into bigger features. I’ll keep updating this post as things move.

Repo: https://github.com/panel-extensions/panel-live-server