March 2026
I got tired of guessing what my MCP server was doing
So I built mcpcat — a CLI tool that connects to any MCP server and lets you poke around from the terminal.
The problem
I run a custom MCP server with 100+ tools. It powers three different AI interfaces — a web dashboard, a CLI agent, and a conversational assistant. Each interface sees a different subset of tools based on “frames” (a filtering system I built so my trading tools don't show up when I'm writing fiction).
The problem: every time I added a tool, changed a schema, or tweaked frame filtering, I had no quick way to verify what was actually exposed. I'd either read the source code, or wire up a test client, or just... guess.
That's a terrible workflow when you have 100 tools across a dozen modules.
What mcpcat does
Four commands. That's it.
# List all tools on a server
mcpcat tools http://localhost:8100/mcp
# Filter by name
mcpcat tools http://localhost:8100/mcp -f paradise
# Inspect a specific tool's schema
mcpcat inspect http://localhost:8100/mcp cortex_signal
# Call a tool directly
mcpcat call http://localhost:8100/mcp health
# Check if a server is alive
mcpcat ping http://localhost:8100/mcp
It auto-detects whether the server uses the newer streamable HTTP transport or the older SSE-based transport. You point it at a URL, it figures out the rest.
The interesting part: transport detection
MCP has two transport modes. The original spec used Server-Sent Events — you open a GET connection to /sse, wait for an “endpoint” event, then POST your JSON-RPC messages to that endpoint. The newer streamable HTTP transport skips the SSE handshake entirely — you just POST directly to the server.
My first version only handled the old SSE flow. When I tested it against my own server, it hung. My server uses streamable HTTP. The SSE endpoint is just a keepalive channel for notifications, not the primary transport.
The fix: try a plain GET first. If the server returns JSON with protocol info, it's streamable HTTP. If not, fall back to SSE. Simple, but it took a real failure to realize I needed it.
The stack
Python, Typer for the CLI, httpx for HTTP, Rich for the pretty tables. Nothing exotic. The entire thing is ~250 lines across two files. It's pip-installable and I plan to publish it to PyPI.
Why build this instead of using existing tools?
Because there aren't any. MCP is still new enough that the tooling gap is wide open. There's no curl equivalent for MCP — something you can just point at a server to see what's there. That's the gap mcpcat fills.
If you're building or consuming MCP servers, you can try it now:
pip install git+https://github.com/AlexlaGuardia/MCPcat.git