pmig

Thanks for the feedback - highly appreciated, I'll reach out on LinkedIn, although we are trying to talk to the same happy folks, I am happy to exchang notes.

Hi HN, I am one of the developers behind the hyprmcp gateway, we summarized all our learnings regarding MCP authentication in this blog post. I am happy to answer related questions here.

I am also running into similar problems, constantly seeing Claude Code warnings that my tools take up a lot of the context window. There are some projects out there that try help you build a unified MCP server (aci.dev, ibm-contextforge, hyprmcp.com[1]). Also the MCP protocol supports a notifications[2] for "dynamically adding tools", but most clients don't support them. A "smart" middle layer still needs to be created.

[1]: Disclosure I am working at https://hyprmcp. Our gateway is fully open source: https://github.com/hyprmcp/mcp-gateway

[2]: https://modelcontextprotocol.io/docs/learn/architecture#noti...

This is great. Once Tool authentication becomes super seamlessly more and more business use cases will get enabled. As building secure remote authenticated MCP servers can be super tricky we are currently and shouldn't be built by every MCP server, we built a MCP Gateway (https://github.com/hyprmcp/mcp-gateway) to put authentication and analytics in front of remote mcp servers.

Feel free to just include our gateway in your docker compose file.

oauth2proxy actually doesn't work for MCP servers due to missing dynamic client registration..

ChatGPT launching MCP support would dramatically improve adoption, but MCP server installation must become way easier to find non coding use case adoption.

Interesting we also just released our mcp gateway project under the name Hypr MCP[1].

[1]: https://github.com/hyprmcp/mcp-gateway

These kind of gateways showcase that larger organizations will equip their employees with tools the same way employees are currently granted access to specific SaaS applications.

One of the bigger challenges we are currently observing is missing authorization for MCP servers.

We actually also just released a mcp-gateway[1] initially focusing on adding OAuth authorization to streamable HTTP MCP servers.

[1]: https://github.com/hyprmcp/mcp-gateway

We actually check from how many different organization the last committers belong to and analyze if the most recent commits have be done by bots (like renovate or dependabot)

Gods point, will work on that!

Most applications are designed in that way, think about ossf scorecard, star-history.com etc..

We did, bur ran into the API limits as oder/scorecard alone is quite expensive on GitHub request

Thanks for the feedback, shouldiuse.dev gave us a lot of information on the first glance.

Thanks scusku, the personal access token does not have any additional permission, we just need to avoid getting rate limited.

It's a good point. I am personally not really a fan of versioned docs. Having a CHANGELOG.md or similar is critical, but how often do you really want to explore the docs in a specific version? And there are also way better options to pinpoint changes. You can think of using git blame instead of clicking through a dozen of point releases of your versioned docs.

Even their status page returns an error: https://support.spotify.com/us/article/ongoing-issues/

Thanks, fixed

This is also what we observe while building Distr. ISVs are in need for a container registry to hand over these images to their customers. Our container registry will be purpose build for this use-case.

AWS Controller for Kubernetes (ACK)[1] provides resources for creating S3 buckets as CR. Also in combination with Pod Identities there is no need for tf.

[1]https://aws-controllers-k8s.github.io/community/docs/user-do...

Actually resizing PVC depends on the CSI drive. Some support easy resizing, some require the volume to be detached. You can double check your CSI driver and might just need to patch your storage class.

Agreed running databases without operators that can handle replication, master promotion backups and PIT restore is super scary. Most of the modern operators support all of these operations.

Yes, but our GitOps repository heavily utilizes Kustomize and Flux, allowing us to reuse a significant amount of code across multiple deployment stages and clusters, which has proven to be very effective.

We have worked with Terraform modules before, but they quickly became difficult to manage.

Additionally, deployments to ECS are typically handled by invoking the AWS API within a GitHub Action, without continuous reconciliation or drift detection.

I agree that ECS works great for stateless containerized workloads. But you will need other AWS-managed services for state (RDS), caching (ElastiCache), and queueing (SQS).

So your application is now suddenly spread across multiple services, and you'll need an IaC tool like Terraform, etc.

The beauty (and the main reason we use K8s) is that everything is inside our cluster. We use cloudnative-pg, Redis pods, and RabbitMQ if needed, so everything is maintained in a GitOps project, and we have no IaC management overhead.

(We do manually provision S3 buckets for backups and object storage, though.)

Exactly! We initially received some sentry errors that triggered our curiosity.

Yes, that is what we thought as well, but it turns out that the there is still a delay between the load balancer controller registering a target as offline and the pod actually being already terminated. We did some benchmarks to highlight that gap.

As PhilippGille pointed out, if you have a permanent connection to your cluster there is no need use Distr. Distr empowers you to ship and monitor your application if you only get a one time access to the deployment target. You can install the agent once and afterwards the agent creates a reverse tunnel (https polling for new actions to perform) that let's you perform upgrades and monitor the deployment even if you are not directly connected to the deployment.

The main advantage is our agent component that gives you insights into the deployment status, even if you are not connected to the host.

You can also perform updates without being connected to the host.

Interestingly this is the problem we initially tried to solve. We build a Kubernetes Operator (back in the day in Kotlin) that does the full life cycle management of these kind of apps. Including management of CRs for database upgrades etc.

This project still runs at customers in production, but ultimately - as you pointed out - individual configurations became to big of a problem as it was not feasible to build a new operator versions for configuration deviations. It was a a fun project though: https://github.com/glasskube/operator

Komodo looks like really cool. It's slightly more focused on managing my own deployments if I have full control of the server!

> Cool. So the tar would be uploaded to the hub and from there the user can manage deployments. Or maybe even create draft? deployments from the gh action and the user would only have to confirm/approve before shipping to clients.

We don't support uploading the actual images these must be hosted in a separate container registry.

> The ability to specify pre-deploy, post-deploy and a custom deploy command (not just docker compose up) would be helpful.

I can see that thanks for the suggestion!

> But not both? Can't the customer invite the vendor back to allow them to perform such actions when necessary?

You'll probably right all of these scenarios are possible, we should make it configurable from both sides: "all the other party to manage the deployment"

> Make it super easy to see if there's a new app version,

Good point "update notifications" are also on our backlog, this feature should be definitely considered.