Hacker News

https://archive.ph/w0izj

This project started when we did what everyone was doing — building a remote MCP server and launching it. Building the first local MCP server for testing was quite simple, and we had our first tools ready within a day. The next step was turning that into a production-ready remote MCP server.

As we exposed the MCP server to our users, we wanted to authenticate them with our existing authentication methods. We dove deep into authentication. Our approach was to build an auth proxy and plug it in front of our MCP. It took a while to figure out Dynamic Client Registration (DCR) and the OAuth spec, and especially the gaps between existing OIDC IDPs and what LLM clients needed.

We thought authentication would be the hard part — but it wasn’t. When we shared the MCP server with a few friendly startups, we realized that different MCP clients behave differently. Especially if something didn't work, it was hard to figure out the root cause. We ended up storing all the raw gRPC method calls to see if the initialization and subsequent requests worked. This is especially useful if you are on a serverless environment with limited debugging functionality, like Cloudflare Workers.

Once we solved auth and compatibility, we launched to a small customer base — done, right? Unfortunately, not quite. Technically everything was working, but when we started talking to users, they told us the MCP server didn’t always respond with the right tools for their prompts. We had a working enterprise-grade MCP server — but it wasn’t very smart. After talking to some startup friends, we realized we needed an evaluation layer. That’s when we added prompt analytics — letting us see which prompts triggered which tools and how well they performed. That alone dramatically improved our MCP’s behavior and overall user experience.

After building all of this into our proxy, we realized that everyone building a remote MCP was facing the same challenges. So we decided to package it all up and release it to the community.

We’re thrilled to launch and open-source HyprMCP. It acts as a proxy that you can plug in front of your MCP server(s) with zero code changes. You get authentication, logging and debugging, prompt analytics, and an MCP connection instructions generator.

Under the hood, HyprMCP leverages dynamic Kubernetes Operators (Metacontroller) to automate infrastructure provisioning.

On the roadmap: MCP aggregation — combining multiple MCP servers under one single remote URL for large organizations running servers with different lifecycles. All of it without storing end user credentials on the server and connecting the MCP to the organizations existing authentication methods.

You can check the project out on GitHub: https://github.com/hyprmcp/jetski

For testing, we also have a hosted version here: https://app.hyprmcp.com

We even created a demo video on YouTube: https://www.youtube.com/watch?v=m2-YyfjXap4

We’d love to get your feedback, hear what features are missing, and learn how you’re building and running your own MCP servers.

https://www.bloomberg.com/news/articles/2025-10-08/the-circu... (https://archive.ph/E7nGC)

After having to do a ton of git stashing and branch fumbling, I decided I needed to something to more ergonomically run these agents in their own dedicated spaces.

I tried a lot of the existing products but they either were too convoluted or flat out didn't work. Some of them also seem to roll their own chat UI which I don't think is the right approach, I wanted to something to lightly wrap my terminal sessions.

So I built FleetCode! It uses git worktrees and let's you run multiple agents at once. It's made my multi agent coding workflow much easier.

It's free and open source, would love some feedback!

The Problem: I use Claude for coding daily, but every conversation starts from scratch. I'd explain my architecture, coding standards, past decisions... then hit the context limit and lose everything. Next session? Start over.

The Solution: Recall is an MCP (Model Context Protocol) server that gives Claude persistent memory using Redis + semantic search. Think of it as long-term memory that survives context limits and session restarts.

How it works: - Claude stores important context as "memories" during conversations - Memories are embedded (OpenAI) and stored in Redis with metadata - Semantic search retrieves relevant memories automatically - Works across sessions, projects, even machines (if you use cloud Redis)

Key Features: - Global memories: Share context across all projects - Relationships: Link related memories into knowledge graphs - Versioning: Track how memories evolve over time - Templates: Reusable patterns for common workflows - Workspace isolation: Project A memories don't pollute Project B

Tech Stack: - TypeScript + MCP SDK - Redis for storage - OpenAI embeddings (text-embedding-3-small) - ~189KB bundle, runs locally

Current Stats: - 27 tools exposed to Claude - 10 context types (directives, decisions, patterns, etc.) - Sub-second semantic search on 10k+ memories - Works with Claude Desktop, Claude Code, any MCP client

Example Use Case: I'm building an e-commerce platform. I told Claude once: "We use Tailwind, prefer composition API, API rate limit is 1000/min." Now every conversation, Claude remembers and applies these preferences automatically.

What's Next (v1.6.0 in progress): - CI/CD pipeline with GitHub Actions - Docker support for easy deployment - Proper test suite with Vitest - Better error messages and logging

Try it:

npm install -g @joseairosa/recall # Add to claude_desktop_config.json # Start using persistent memory

https://fightchatcontrol.eu/