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.
He hinted at wanted to be convinced to work at the company. It seems as if he wants people to just know he’s good and people offer him the job instead of applying for it. It’s a bit contradictory since he applied for the job in the first place.
From this interview https://youtu.be/Nlkk3glap_U?feature=shared it seemed Anthropic was focusing more on those topics rather than winning the race. He hinted at being “forced” by the competition to release their models.
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).
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.
Maybe I didn’t explain the process correctly, we do generate the spec first, it’s just that the tool we use for creating the spec is the code that will later contain the implementation.
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 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?