I got tired of vibe-testing my MCP servers, so I built a Bruno-style client for MCP

#mcp #claude #chatgpt #opensource

I've been writing MCP servers for a few months now, and most of that time was spent staring at JSON. Hand-writing request payloads, eyeballing responses, mentally diffing nested objects to check if a tool call actually worked. My "testing" wasn't much better: point an LLM at the server, ask it to try some tool calls, read the vibes.

That's not testing. That's hoping.

Here's the thing — LLMs are non-deterministic by design. Your protocol layer isn't supposed to be. If your tool returns the wrong shape, a missing field, or a broken error response, you don't need a model's opinion about it. You need a failing assertion.

So I built MCPFlo — an offline-first, open-source, MIT-licensed Electron app for testing and debugging MCP servers. The core idea is boring on purpose: deterministic assertions against real protocol responses.

expect(result.isError).to.equal(false);
expect(result.content[0].type).to.equal("text");
expect(json.total).to.be.a("number");

If it passes, it passes every time. If it fails, you know exactly where. No vibes involved.

What it does

Chai.js-style assertions against real tool responses. Write expect().to.equal() tests for your tools, resources, and prompts. Run them against the actual server, not a mock.
Auto-generated forms from your schemas. MCPFlo renders your tool's input schema as a proper form — including nested objects and arrays — via RJSF. Stop hand-writing JSON payloads for every tool call. If your schema is deep and ugly, that's exactly when this matters most.
Token budget visualizer. See what your tools, resources, and prompts actually cost against different model context windows — before you find out the expensive way. An MCP server with 40 verbose tool descriptions is quietly eating someone's context budget. Now you can see it.
OAuth 2.1 support, so you can test servers that actually require auth instead of stripping it out for local dev.
Fully offline. No telemetry, no cloud dependency, no login, no server-side anything. Your requests and test data live on your machine as git-friendly JSON.

What it deliberately doesn't do

MCPFlo won't tell you whether an LLM uses your tools well — whether your descriptions are clear enough for a model to pick the right tool at the right time. That's behavioral evaluation, and it's a different layer of the stack. MCPFlo covers the layer below it: does your server actually do what the protocol says it does?

Both layers matter. This tool is for the deterministic one.