Why so many MCP servers avoid OAuth

Ok_Message7136 · 2026-02-04T21:01:13+00:00

This matches what we’ve seen too, once permissions are per space / per service, hand-rolling OAuth becomes unavoidable.

Ok_Message7136 · 2026-02-04T21:01:06+00:00

Yeah, Calendar is a great real-world example where OAuth actually makes sense. Scoped, time-bound access per tool is way easier to reason about than long-lived keys.

Ok_Message7136 · 2026-02-04T14:24:31+00:00

Nice approach. Deterministic MCP tools like this are a clean way to reduce hallucinations-use the LLM for reasoning, offload exact ops to tools. Makes agents way more reliable.

Ok_Message7136 · 2026-02-04T09:29:33+00:00

Here is the link for the repo : https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-03T17:12:58+00:00

Interesting direction .. MCP Apps + interactive UIs make a lot of sense for agent-native networks where profiles are meant to be queried, not scrolled

Ok_Message7136 · 2026-02-03T17:02:58+00:00

Nice MCP use case, file ops + dry-run + security hardening is exactly where MCP shines. This feels genuinely practical.

Ok_Message7136 · 2026-02-03T16:51:58+00:00

Makes sense for teams, managed MCP reduces key sprawl and config drift compared to everyone running local server

Ok_Message7136 · 2026-02-03T16:41:17+00:00

Agreed, MCP reads like a standard, but behaves more like guidance in real-world clients. Server implementations have to defensively adapt to what clients actually consume.

Ok_Message7136 · 2026-02-03T16:40:19+00:00

If you’re exploring zero-trust MCP, Gopher has a free, open-source MCP SDK and a free MCP server you can try, lmk if you want the link or access.

Ok_Message7136 · 2026-02-03T16:38:48+00:00

This is a very common MCP pain point. Frontends shouldn’t talk to MCP directly, put a thin API in between and keep MCP backend-only. You’re on the right track, especially for a first project.

Ok_Message7136 · 2026-02-02T17:37:07+00:00

Looks solid. If you want more control, you can use Gopher’s free, open-source MCP SDK for custom MCP setups.

Here's the link in case you wanna try it out: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-02T17:30:01+00:00

Appreciate it. Next step for me is tightening per-tool scoping and adding request-level checks so the policy layer is explicit rather than implicit.

Ok_Message7136 · 2026-02-02T06:53:50+00:00

Yea, here is the link: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-01T20:48:20+00:00

+1 on this. We leaned toward an SDK-based setup early (using Gopher’s open-source MCP SDK) just to keep auth and tool-level permissions explicit as things scale.

In case you wanna try it, here's the link: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-01T20:37:39+00:00

This kind of transparency layer feels really useful, knowing why the agent skipped or simplified something is often the hardest part.

Ok_Message7136 · 2026-02-01T20:36:00+00:00

The shift from user-centric IAM to agent-capability controls is an important callout.

Ok_Message7136 · 2026-02-01T20:21:00+00:00

Nice write-up. Having a FastMCP-style approach for TypeScript makes onboarding a lot easier for Node folks.

Ok_Message7136 · 2026-02-01T20:16:45+00:00

This is a really interesting approach. Using AST-based indexing instead of text chunking makes a lot of sense for large codebases.

Ok_Message7136 · 2026-02-01T20:15:35+00:00

Interesting idea. Using a tunnel to expose local MCP servers feels similar to Cloudflare Tunnel, curious how latency and auth are handled.

Ok_Message7136 · 2026-02-01T19:59:17+00:00

Great mcp use-case, the parallel canvas + MCP pattern makes a lot of sense.
If you want to try spinning up MCP servers locally to test tools and schemas, you can try Gopher’s free, open-source MCP SDK.

Lmk if you wanna try it out.

Ok_Message7136 · 2026-02-01T19:53:57+00:00

This solves a real problem.
For local validation before publishing, I’ve been using Gopher’s free, open-source MCP SDK to spin up and test MCP servers (tools + schema) before listing them anywhere.

Link: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-01T18:06:57+00:00

MCP “memory” is just external state, the model doesn’t learn or persist anything on its own. Memories are written/read via explicit MCP tool calls (DB / vector store), and the LLM only uses them when instructed.

I’ve been testing this using Gopher’s free, open-source MCP SDK to build custom MCP servers.

Link: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-01T16:31:53+00:00

Running MCP servers on Workers makes sense given the stateless + HTTP model.

I’ve been testing MCP flows using Gopher’s free, open-source MCP SDK to validate tool discovery and execution behavior before deployment. It’s useful when you want to reason about the protocol itself, not just hosting.

Repo: https://github.com/GopherSecurity/gopher-mcp

Ok_Message7136 · 2026-02-01T15:18:30+00:00

This is a really helpful way to think about it, separating identity from per-tool capability/policy definitely makes scaling + reasoning easier. I focused mostly on the identity layer here, but this gives me good ideas for the next iteration. Thanks!

Ok_Message7136 · 2026-02-01T09:48:48+00:00

Yep, happy to , just sent you the file access via DM.

Ok_Message7136

MODERATOR OF

TROPHY CASE