7 pointsby rupatiwari257 hours ago4 comments
  • guerython7 hours ago
    Love the hosted SSE/HTTP mirrors and registry. We built something similar to catch handshake drift in our remote MCP clients, and being able to replay the JSON-RPC log in-browser saved us from chasing environment-specific timeouts because we could rerun the exact frame sequence from the failure. One idea: add a little health badge per server showing last-seen transport (HTTP/SSE/WS) plus a running error count so integrators know which endpoint matches their stack before they flip the switch.
    • rupatiwari256 hours ago
      Really appreciate this — handshake drift is a real issue in MCP setups. Also love the health badge idea (showing last transport + error count would be super helpful).

      Thanks for sharing

  • mt187 hours ago
    Any plan to support ws transport ? A few newer mcp servers are moving away from SSE
    • rupatiwari257 hours ago
      yes, it’s in the pipeline.
      • mt187 hours ago
        I liked the recipe part though especially the Meta Ads one, you can keep it open for others to contribute as well—it could help increase engagement.
  • jacksm12432 hours ago
    Add a dark mode
  • nikhiltiwari257 hours ago
    How is this different from MCP Inspector?
    • rupatiwari257 hours ago
      Inspector is the right tool for local STDIO servers — use it. We're complementary, not competing.

      MCP Playground fills a different gap: no install (browser tab, nothing to run), built for remote HTTP/SSE endpoints rather than local processes, and includes hosted test servers so you can verify your client implementation without needing a server at all. Plus a registry if you're trying to discover what's out there.

      Inspector ideal for: STDIO, local debugging, open source, deeper protocol introspection. MCP Playground for: zero setup, remote servers, client testing, browsing mcp registry/server list.