HN user

barefeg

180 karma
Posts7
Comments190
View on HN

For some time, authentication was not part of the MCP. Now it’s there https://modelcontextprotocol.io/specification/2025-03-26/bas... so I’m wondering what is being addressed in Klavis. Is it something that the reference implementation of MCP lacks? If so, will it eventually make it to MCP?

I think it’s important to release SDKs that are secure by default, so not providing this in the reference MCP would be a big issue.

In my view, MCP should be maintained by the vendors themselves. It’s too complicated to use in the enterprise if everything comes from the community with questionable security. So I applaud initiatives that try to solve this. I think smithery.ai provides something similar while also being a repository of servers (I’m not associated with them), but again the problem is needing to trust an extra middleman vendor.

Does anyone else share this view? For example, will AWS (or insert any other hyperscaler) end up providing the “Bedrock” of MCP where security is native to the platform? Or will individual companies (Box, Google, MS, etc.) start rolling them out as part of their standard developer APIs?

Thanks for sharing your blogpost. We had a similar journey. I installed and tried both Langfuse and Phoenix and ended up choosing Langfuse due to some versioning conflicts on the python dependency. I’m curious if your thoughts change after V3? I also liked that it only depended on Postgres but the scalable version requires other dependencies.

The thing I liked about Phoenix is that it uses OpenTelemetry. In the end we’re building our Agents SDK in a way that the observability platform can be swapped (https://github.com/zetaalphavector/platform/tree/master/agen...) and the abstraction is OpenTelemetry-inspired.

This technique had a very recent resurgence via https://txt.cohere.com/int8-binary-embeddings/. Hugging face also covered the technique here https://huggingface.co/blog/embedding-quantization. It seems like a very good tradeoff compared to the shorter embeddings which require fine tuning via the matryoshka technique. On the other hand, Nils Reimers suggests that trivial quantization of the full precision embeddings is not as good as using “compression friendly” embeddings like Cohere’s Embed V3. Does anyone know what’s the difference in precision between trivial quantization and optimized embeddings?

I wish they had cut all benefits from tier 3 companies only^[1] while leaving other tiers intact. Big tech salaries in Europe are already so much higher in comparison, that it would probably not impact their ability to hire.

On the contrary, tier 1 and 2 companies already have a hard time hiring even with the benefit (from personal experience).

[1] highest band in the trimodal salary distribution https://blog.pragmaticengineer.com/software-engineering-sala...

We started with something like this as well. The problem is that the savings and disposable income will also be proportional. If the difference in salaries is large then it could seem unfair. But then again it depends whether you view wealth as an individual or shared affair.

Does splitting here mean each person pays half of the price of the shared item? If so that puts more pressure on the lower earner. One approach would be to put both incomes in a big pot, take all the shared expenses from that pot, and then divide and distribute the rest between the two.

Thanks. I missed this part https://openapistack.co/docs/openapi-backend/typescript/ so the types are generated for the backend to use. We’ve used API first approach before, but it was very painful to keep the types in sync. Now we’re transitioning to FastAPI which allows to more or less create the OpenAPI types in code (via pydantic which can export the python types into OpenAPI schema).

We now follow a kind of hybrid approach in which the routes and types are created in code first, without actual implementation (just return 404). This auto generates the spec.yaml as well as any vendor code we might need (via client generator). I think this is quite a productive workflow as well because the type generation in code is more convenient than typing yaml by hand and everything is always in sync

You can try the 3 methods: keyword, knn, and hybrid on a collection in the AI domain here https://search.zeta-alpha.com/. YMMV sometimes knn has more interesting results, sometimes keyword is closer to what you wanted. Hybrid is sometimes also a good middle ground. But it fails when one of the retrievers has very bad results (because it will interleave them)

I feel like something is missing. I see the positive feedback what what about the feedback after rejection?

The answers so far tend to be either: yes, it’s very easy. Just follow a boot camp or books, transition at work by working close to a DS/ML team, etc., or no, you need lots of background knowledge, track record of publications, etc.

I think the problem seems to be that there’s not a clear need for engineers with lower levels of expertise in some of the fields; that is people with less than an MS degree in that specific ML sub field.

If the field transcends for long enough, and urgent demand becomes so mainstream, then I imagine hiring managers will have to invest more resources in hiring people with less experience and training them in the job. Similar to how developers are hired fresh out of short boot camps these days.

Therefore the easiest way to transition would be by acquiring practical an theoretical knowledge using the strategies given in the other answers and then applying to ML teams where there’s enough demand for them to want to train you in the job. Of course that’s easier said than done. It might be interesting to hear some thoughts on whether this is already happening in certain fields.

Kind of off topic. But is there any app/service/extension for parsing these TOS with an LLM to catch all these shady things? If not, would one be useful? (I’m also a bit surprised this is in the TOS in the first place, but theres already a thread about that.)

Maybe a clarification: it doesn’t need both the app and internet connection to unlock. There are 2 ways to unlock and one of them uses the app and Bluetooth (no internet).

In terms of the appeals, I see it the other way around. The app is just the means to get the feature set to work; people don’t buy the bike because it has an app. There might be other implementations of the features that don’t require an app.