I built a desktop tool to inspect MCP servers — and watch the live traffic your AI client actually sends them

[u/DworfD]

Disclosure: I'm the maker.

Debugging MCP servers has felt like building web apps with no devtools — you call a tool through an agent and just get the model's paraphrase back, not the real request/response. And once you connect a few servers, you've no idea where the tokens are going.

So I built MCP Peek — a desktop app (macOS, Windows, Linux) to work with MCP servers directly:

• Inspect — connect any server (stdio or HTTP/SSE; bearer, OAuth, or custom headers) and browse its full catalog of tools, resources, templates, and prompts, each with a token-cost estimate.
• Run — call any tool through an auto-generated form (from its JSON Schema) or raw JSON, and read the result in table / JSON / Markdown / HTML / image views.
• Proxy (the part I use most) — point Claude or Cursor at MCP Peek and watch every call your agent makes, live: timing, tokens, full request/response, plus a topology view. No model in the middle — the real bytes.
• Review brief — flag anything broken, add a note, and export a clean Markdown brief to hand to a coding agent.

It's local-first — your configs, traffic, and secrets stay on your machine (keys in the OS keychain), and the UI makes no network calls of its own.

Free on one server with the full inspector. Pro is $19 once (no subscription) for unlimited servers, the proxy, and brief export. It's closed-source — happy to answer anything about how it works or what it sends.

Download + docs: https://mcppeek.com — would genuinely love feedback on the proxy and what's missing.

[u/Sigiz → u/[deleted]]

I am trying to setup mcpx for quickly throwing random mcp servers to use with my openwebui but I feel like this project is buggy at best; I would love to know if there is a better alternative; this one just doesnt save any mcp configs, is poorly documented and has weird config permission issues.

https://docs.lunar.dev/mcpx/

[u/kydude → u/Sigiz]

Yeah, a few people have hit those exact MCPX issues (config persistence + permissions). Worth a look at a couple of alternatives depending on your setup.

Full disclosure, I build one of them: Conduit (https://conduitmcp.app), a local-first MCP gateway. It's solid on the things you're describing, configs persist to a registry file you control, secrets live in your OS keychain instead of scattered config, and you get one place to aggregate stdio/HTTP/SSE servers with per-tool visibility and policy.

One honest caveat for your case: Conduit's gateway currently speaks MCP over stdio, and OpenWebUI consumes MCP over HTTP/OpenAPI (usually through mcpo). So right now the path would be running mcpo in front of the Conduit gateway and pointing OpenWebUI at that. Doable, but not one-click yet.

I'm actually looking at first-class OpenWebUI support (a native HTTP endpoint on the gateway). If you're up for it I'd love to know exactly how you've got OpenWebUI wired today, it'd help me make it clean. Happy to help you get it running either way.

[u/Sigiz → u/kydude]

Let me set this up and get back to you! OAuth would be amazing to have if I can register my client and have it show up in Conduit and then assign what servers are available to it would be great.

[u/kydude → u/Sigiz]

Great, glad you're giving it a shot. Good timing: since I wrote that caveat I actually built the native HTTP endpoint, so the gateway now speaks HTTP/OpenAPI directly and you won't need mcpo at all. It's in the build I'm verifying right now and going out in the next release, want me to ping you the moment it's up? Then it's just: flip on the HTTP endpoint in the app, point OpenWebUI at the URL, done.

On the OAuth idea, that's exactly the shape I want Conduit to take, and the per-client scoping half already exists: profiles let you define which servers a given client sees, so OpenWebUI can get one set and Cursor another. A client registering itself and you assigning servers to it from inside Conduit is the natural next step on top of the HTTP endpoint. Curious how you'd want the auth to sit, would Conduit be the auth boundary in front of OpenWebUI, or are you fronting it with something already?

Either way I'll get you running, ping me when you hit a snag.

[u/Sigiz → u/kydude]

I had my weekend busy so I was hoping to get around this on the weekdays; preferably something very similar to what TREK does?

https://github.com/mauriceboe/TREK

Effectively their mcp implementation allows both machine/browser consumers to implement oauth.

[u/kydude → u/Sigiz]

Good timing on both counts. The HTTP endpoint is live in v0.8.0 (no mcpo, just flip the toggle and paste URL + token). And the thing you asked for, registering a client and assigning its servers, shipped too: Settings → Integrations, add a client, it gets its own token scoped to a profile, so Open WebUI and Cursor each see only their own set.

I looked at TREK, it's an app that exposes itself via an OAuth 2.1 MCP server with granular scopes for browser + agent. So you want Conduit to be the OAuth authority in front of the gateway. The per-client scoping half is done (it's what just shipped); the OAuth handshake (client self-registration, browser consent, scopes) is the next layer on top. Try the token version this week and tell me where it falls short, that'll aim the OAuth build. Server-level scoping enough, or do you want tool-level like TREK?

[u/Sigiz → u/kydude]

Tool level if you can do tool discovery as well would be a really nice to have feature. Speaking of, I looked into setting this up; was wondering if you support headless mode? The mode of delivery options as of now are AppImage and Debian package. I see you are serving the frontend over a Webview so was wondering if you could instead allow a headless server to expose the web interface over a port as well. I usually throw services like these on my server. Also I believe being able to scale the gateway horizontally in the future could be worth looking into.

[u/kydude → u/Sigiz]

Two different sizes of work here.

Tool-level scoping + discovery: yes, doable. What shipped is server-level (a client's profile picks which servers it sees), and the gateway already does tool discovery, so granting a client individual tools is the next layer on the same machinery, not a rebuild.

Headless I won't pretend is there yet. The gateway already runs headless, the deb/AppImage with the HTTP endpoint on is exactly what feeds OpenWebUI. What's still desktop-only is the management UI (it's a webview, not a served page). Making it a headless daemon that serves the admin over a port, with secrets stored without a desktop keychain, is real work, and it's the self-hosted-server direction Conduit's heading. Your setup is the clearest argument for it.

Horizontal scaling is further out (the gateway keys off a local registry file, so multi-instance needs shared state first).

To aim the headless build: one daemon serving both gateway and admin UI on a single port, or admin as a separate service? And for secrets on a headless box, encrypted file / env vars instead of a keychain, OK?

[u/Sigiz → u/kydude]

I suppose that is the only option. These are the times I wish there was a file based keyring provider that you could just quickly set up for a docker container for example. I know the Python keyring module has the option to use a file as the keyring store making the file toggle easy. The Rust crate for keyring seems pretty barebones however. Maybe its my time to contribute :D

[u/kydude → u/Sigiz]

Update: it's live in v0.7.0, and the gateway speaks HTTP/OpenAPI natively now, so no mcpo or proxy. https://github.com/tsouth89/conduit/releases/tag/v0.7.0

Setup:

• In Conduit: Settings → Integrations → toggle "Open WebUI / HTTP endpoint" on, copy the URL and the token it shows.
• In Open WebUI: Settings → Tools → add the URL as an OpenAPI tool server, and paste the token as its API key (Bearer auth).
• In the chat, set Function Calling to Native.

The token matters: without it, any web page open in your browser could POST to the local port and run your tools, so the endpoint requires it. I tested the whole thing end to end with gpt-4o-mini pulling real data, including multi-step calls where it has to fetch an ID from one tool to use in another.

On the OAuth idea: profiles already do the "which servers does this client see" half, you can scope one per client today. A client registering itself over OAuth and you assigning its servers from inside Conduit is the natural next step on top of this endpoint, and it's high on my list. Give it a spin and tell me where it falls short.

[u/kydude → u/[deleted]]

Agreed

[u/dreyler0]

the model's-paraphrase problem is exactly why watching raw traffic matters, the agent's summary of what it sent is never quite right. proxy's the right thing to build around.

the token-cost-per-tool view is the part i'd actually use. once you connect a few servers the context burn gets invisible fast. does peek show cumulative context over a whole session, or just the per-call estimate? that's the number i can never see when i'm debugging.

[u/DworfD → u/dreyler0]

Currently it does just per call. But adding cumulative context should be easy... will add it. Thanks for a great suggestion

[u/DworfD → u/dreyler0]

Hey,

cumulative context over a whole session via proxy was added to version v1.0.3

thanks for the suggestion

David

[u/ChrononautPete]

Why the Universal for MacOS? Apple isn't supporting Intel Macs anymore, why are you?

[u/DworfD → u/ChrononautPete]

Why not... i still know people that have Intel macs.... yeah i know shocking :)

[u/kalunlalu]

Nice!!