A lot of how well it works or won't work depends on your clients, as not all clients have support for things like RFC 9728 (Protected Resource Metadata). Assuming your client has good support for most of the OAuth 2.0 standards that MCP uses (you don't need DCR as you can statically register clients, assuming that is viable for your environment), then it is possible now with most IDPs to get an OAuth 2.0 auth code flow working just fine. You would then do a token exchange to the upstream to ensure to get the appropriate new audience and rescope/downscope as necessary. Gateways can also help here a lot as instead of baking in all of the auth concerns into your MCP Servers and upstreams, you delegate that to the MCP Gateway. Again, gateway here means different things to different vendors, but Kong, for example, has the ability to act as an MCP proxy (gateway), expose tools based on consumer role or group, apply OAuth 2.0 to it and do an upstream token exchange, while also acting as a regular API gateway that can protect an endpoint with OAuth 2.0/OIDC.
Doing a workshop this week on MCP for an enterprise client and explaining the 406 returned by GET against /mcp w/o text/event-stream is exactly one of the things that I have to bring up when I do these.
The specification still leaves a lot to be desired, especially as it relates to auth. There are lots of bad ways to do auth with MCP and only a couple of good ways. It also puts a lot of pressure on the various IdP vendors and relies on lesser used areas of OAuth 2.0/2.1 (like DCR, token exchange, etc.). It started out in a place where the assumption was you were running an MCP Server on a laptop or you were a SaaS provider serving lots of individual users -- somehow DCR in the initial spec iteration seemed like a good idea (spoiler: it wasn't) and fortunately, the latest revision has somewhat addressed that. XAA/ID-JAG & CIMD should continue to round-out some client management and auth solutions for the enterprise.
Gateways are another area that needs to be addressed in the spec. There isn't a formal definition of one in the spec, and yet, there are lots of "gateways" out there. What a gateway is and what it should do is an open question and it means different things to different people depending on who you ask. For example, who does token exchange: the MCP server or the MCP gateway? Both are valid answers right now depending on the implementation or your opinion of which is best.
More spec iterations should be coming this year. I'm still pretty optimistic about MCP as a whole, as it remains a good way to standardize tool calls across agents and some of the other entities that it provides like resources and prompts are genuinely useful to add more determinism to an agent. Interceptors and skills will be good, too.
If you're interested in helping to evolve the spec further, the MCP Contributors Discord is active. There are lots of IGs/WGs that solicit feedback and you can participate in meetings with your feedback.
Fond memories of buying cheap Sun gear around 2005-2007. I had an E4500, Blade 1000, and a Tadpole SPARCbook 6500 that I ran Solaris 10/11 on along with a couple of Sun Rays. Used the Blade 1000 as a Sun Ray server and it was a great experience. Glad to see it is still alive and kicking in some form.
Valid, but for all the crap that LangChain gets it at least has its own layer for upstream LLM provider calls, which means it isn't affected by this supply chain compromise (unless you're using the optional langchain-litellm package). DSPy uses LiteLLM as its primary way to call OpenAI, etc. and CrewAI imports it, too, but I believe it prefers the vendor libraries directly before it falls back to LiteLLM.
Not just as a gateway in a lot cases, but CrewAI and DSPy use it directly. DSPy uses it as its only way to call upstream LLM providers and CrewAI falls back to it if the OpenAI, Anthropic, etc. SDKs aren't available.
Yep, I think the worst impact is going to be from libraries that were using LiteLLM as just an upstream LLM provider library vs for a model gateway. Hopefully, CrewAI and DSPy can get on top of it soon.
Yep, DSPy and CrewAI have direct dependencies on it. DSPy uses it as its primary library for calling upstream LLM providers and CrewAI falls back to it I believe if the OpenAI, Anthropic, etc. SDKs aren't available.
LangChain at least has its own layer for upstream LLM provider calls, which means it isn't affected by this supply chain compromise. DSPy uses LiteLLM as its primary way to call OpenAI, etc. and CrewAI imports it, too, but I believe it prefers the vendor libraries directly before it falls back to LiteLLM.
This is bad, especially from a downstream dependency perspective. DSPy and CrewAI also import LiteLLM, so you could not be using LiteLLM as a gateway, but still importing it via those libraries for agents, etc.
Very similar experience to my own. Was a 1P customer for years, but the product declined after the VC purchase and I trust Apple more to get privacy & security right. Apple Passwords accomplishes the minimum of what I want a Password system to do. Yes, 1Password has some nice add-ons like SSH agent integration, secure notes, etc., but some of these aren't necessary or have workarounds as outlined in this post.
I really do wish there was some way to integrate Apple Passwords with Linux, but I don't see that happening. FWIW, iCloud on Windows isn't horrible and has decent Apple Password support as it even works with iCloud Advanced Data Protection now.
I've asked multiple OpenAI employees on X that have been posting about the issue whether or not they will be processing bulk unclassified Americans' data or what will they do when asked since I think it is fair to assume that they have or will receive the same ask that was made of Anthropic. No response, yet. The Head of National Security Partnerships at OpenAI seems to be focused on stating that that the NSA is not able to use the contract. Whether or not that is true, it doesn't address the unclassified bulk data processing concern, which is a form mass surveillance of Americans. Also, not great when at least one OpenAI employee has posted that the DoD "does not conduct domestic surveillance" and only issued a correction after quite a backlash by stating that he was only quoting the Under Secretary of Defense.
"Even as Mr. Trump published the post at 3:47 p.m., the two sides kept talking. Mr. Michael, who was on a call with Anthropic executives at the time, said the Pentagon wanted the company to allow for the collection and analysis of unclassified, commercial bulk data on Americans, such as geolocation and web browsing data, people briefed on the negotiations said.
Anthropic told the Pentagon that it was willing to let its technology be used by the National Security Agency for classified material collected under the Foreign Intelligence Surveillance Act. But the company wanted a legally binding promise from the Pentagon not to use its technology on unclassified commercial data."
"Anthropic’s team was relieved to hear that the government would be willing to remove those words, but one big problem remained: On Friday afternoon, Anthropic learned that the Pentagon still wanted to use the company’s AI to analyze bulk data collected from Americans. That could include information such as the questions you ask your favorite chatbot, your Google search history, your GPS-tracked movements, and your credit-card transactions, all of which could be cross-referenced with other details about your life. Anthropic’s leadership told Hegseth’s team that was a bridge too far, and the deal fell apart. Soon after, Hegseth directed the U.S. military’s contractors, suppliers, and partners to stop doing business with Anthropic. The list of companies that contract with the military is extensive, and includes Amazon, the company that supplies much of Anthropic’s computing infrastructure. The Department of Defense did not respond to a request for comment. A spokesperson for Anthropic referred me to the company’s statement addressing Hegseth’s remarks."
Considering they asked Anthropic to participate in the following, I would say this is by design in the OpenAI arrangement:
"Anthropic’s team was relieved to hear that the government would be willing to remove those words, but one big problem remained: On Friday afternoon, Anthropic learned that the Pentagon still wanted to use the company’s AI to analyze bulk data collected from Americans. That could include information such as the questions you ask your favorite chatbot, your Google search history, your GPS-tracked movements, and your credit-card transactions, all of which could be cross-referenced with other details about your life. Anthropic’s leadership told Hegseth’s team that was a bridge too far, and the deal fell apart. Soon after, Hegseth directed the U.S. military’s contractors, suppliers, and partners to stop doing business with Anthropic. The list of companies that contract with the military is extensive, and includes Amazon, the company that supplies much of Anthropic’s computing infrastructure. The Department of Defense did not respond to a request for comment. A spokesperson for Anthropic referred me to the company’s statement addressing Hegseth’s remarks."