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?
Yes thank you! the newest MCP spec added the authentication part but it seems that people think it is still not perfect and are doing more modifications to the auth part. E.g. https://github.com/modelcontextprotocol/modelcontextprotocol.... We will also keep an eye on the spec development.
I'm actually actively looking for something like this. But I'm not sure it fulfills my requirements.
Here is what I'm looking for
- curated open source MCP servers
- trusted curator
- direct oauth integration, so the user permission is taken over (e.g.: you login with your companies Microsoft account and not with the account of the AI-Client.) this is a must for enterprise
- easy to ship (eg.: via electron app)
- I as the developer or the company owner can decide what servers are available to the user, and what tools (e.g.: most companies I talk to want read only access for their employees)
If Klavia fulfills that I would like to have a chat :)
This looks great will definitely have a look. What I wish that there was also MCP client (SDK) for mobile devices either native (Swift / Kotlin ) or React Native / Expo ( ideally with integration with vercel ai sdk). For mobile dev this would simplify setup (not need to have a proxy server) and allow business models with end-user Bring-Your-Own-Key.
This looks like it would add nothing. MCP's were released like 2 seconds ago, if you want to build something in prod, you can build it against the official MCP code.
If you want to add something in the middle or a MCP specific dependency it should add some value, some specific value: industry specific, or add some specific feature.
This is just a generic dependency that provides overly generic features like "production ready" and "integration" (that's true for all dependencies.
Par for the course for AI companies, "do everything for everyone"
This looks interesting! I'll be keeping an eye on it. A few questions that come to mind:
- Is there a way to run it locally/self-host?
- Are there discovery endpoints to list the available servers?
- The 'Test & Eval' page is interesting to me, as I think unpredictability of results with multiple MCP prompts/sources interacting is generally a pretty big issue with MCP, so a good integrated eval system could be valuable. I see it's not launched yet, but it would be great to know more about how this will work.
Agree on the unpredictability of results issue. Tool call selection is still sort of a black box.
How do you know what variations of a prompt trigger a given tool to be called or how many tools is too many before you start seeing degradation issues because of the context window. If you are building a client and not a server the issue becomes even more pronounced.
I even extracted the Claude electron source to see if I could figure out how they were doing it, but it's abstracted behind a network request. I'm guessing the system prompt handles tool call selection.
I'm working on a coding agent, and MCP has been a frequently requested feature, but yeah this issue has been my main hesitation.
Getting even basic prompts that are designed to do one or two things to work reliably requires so much testing and iteration that I'm inherently pretty skeptical that "here are 10 community-contributed MCPs—choose the right one for the task" will have any hope of working reliably. Of course the benefits if it would work are very clear, so I'm keeping a close watch on it. Evals seem like a key piece of the puzzle, though you still might end up in combinatorial explosion territory by trying to test all the potential interactions with multiple MCPs. I could also see it getting very expensive to test this way.
I actually came across Plandex the other day. I haven't had the chance to play around with it yet, but it looked really cool.
But agree that even basic prompts can be a struggle. You often need to name the tool in the prompt to get things to work reliably, but that's an awful user experience. Tool call descriptions play a pretty vital role, but most MCP servers are severely lacking in this regard.
I hope this a result of everything being so new and the tooling and models will evolve to solve these issues over time.
Yeah, I'm still wondering if MCP will be the solution that sticks in the long run.
It has momentum and clearly a lot of folks are working on these shortcomings, so I could certainly see it becoming the de facto standard. But the issues we're talking about are pretty major ones that might need a more fundamental reimagining to address. Although it could also theoretically all be resolved by the models improving sufficiently, so who knows.
Also, cool to hear that you came across Plandex. Lmk what you think if you try it out!
1. Giving the model too many choices. If you have a lot of options (like a bunch of MCP servers) what you often see in practice is that it's like a dice roll which option is chosen, even if the best choice is pretty obvious to a human. This is even tough when you just have a single branch in the prompt where the model has to choose path A or B. It's hard to get it to choose intelligently vs. randomly.
2. Global scope. The prompts related to each MCP all get mixed together in the system prompt, along with the prompting for the tool that's integrating them. They can easily be modifying each other's behavior in unpredictable ways.
Right, my workflow to get even a basic prompt working consistently rarely involves fewer than like 10 cycles of [run it 10 times -> update the prompt extensively to knock out problems in the first step]
And then every time I try to add something new to the prompt, all the prompting for previously existing behavior often needs to be updated as well to account for the new stuff, even if it's in a totally separate 'branch' of the prompt flow/logic.
I'd anticipate that each individual MCP I wanted to add would require a similar process to ensure reliability.
Cool, that's fine with me, but my suggestion fwiw would be to make this crystal clear upfront so you don't risk people feeling misled.
I would also personally consider just open sourcing everything (or at least core features) as I think you'd still have plenty of customers who would prefer a hosted solution. In my experience, there is surprisingly little overlap between the people who prefer cloud vs. self-hosting, so having a full open source option doesn't cannibalize the product side as much as you might think... people who prefer cloud will mostly still prefer it even if they could self-host instead, and people who prefer self-hosting will generally just look for another project rather than using your cloud service. Just my unsolicited 2 cents.
Hi yes so if you just use it yourselves locally in Cursor, I think you can definitely just use the official GitHub MCP. But there might be more use cases where people want to connect MCP servers in their AI agents and deploy it in the cloud, then the local GitHub server would not be a fit.
The UX for end user OAuth is the standard GitHub Oauth flow. You will see a webpage saying that an GitHub Oauth App is requesting access to your github and you need to select yes/no.
The API is for our hosted version. For open source, you can go to https://github.com/Klavis-AI/klavis and check the comprehensive readme. I think we have readme for every MCP server and client and how to set that up.
Hi! Thank you for catching this! I have fixed it right away. This is valuable feedback and I really appreciate it. Now the quick start points to the list of readmes and the hosted version is in the second half of the readme with a clear section Hosted Solutions.
in terms of one mcp to rule them all, it is something on our roadmap now. We are thinking that you can connect to all of the MCP servers we provide with a single URL and you can turn on/off the MCP servers in a simple UI or through API call. Let me know if this is what you have in mind.
Right now, as you know we’re in a total Wild West with this. So the experience is different for each client (VS code, cursor, etc)
To me, the ideal the UX is similar to the extensions UXs in each IDE, you search, click install, and get on with your life after doing an OAuth dance. Or even a discovery mechanism built into the agent itself. Sort of a “have you considered installing this? I can talk directly to JIRA for you” etc
The next best thing would be a catalog where I search, and with a single install button that would add the MCP to a certain IDE. But do the IDEs make this sort of API available, given that they all want to differentiate?
I like from what I see and the option of self hosting. Does it have a middleware like feature to extend, say I want to add more apps than what is provided out of the box ?
Honestly, feels like every time I look at this stuff, the basics like consistent auth and real standards are still kinda up in the air. I keep thinking the endless remixing happens because nobodys happy with defaults yet. You think well ever land on one real standard or is everyone just gonna keep rolling their own forever?
The interesting question is what are your respective end games and do they compete? By this I mean like Facebook was seemingly a face book for college campuses at first.
MCP is a new protocol from anthropic to standardize sharing tools and context with LLMs. Before, the tool calling api from openai was standard but tool makers all built their own mechanisms for defining and sharing tools.
It's a bit of a stretch but MCP is to LLM enabled applications what REST is to web applications.
What was happening before was if you built tools using langchain, you'd have to rewrite them for crewai, cursor, etc. Now, we have a way to share tools, resources, and prompts with applications built using different frameworks.
I've seen a number of projects re-implement the same MCP servers that exist elsewhere, and I wonder if we're doomed to do this over and over and over again. One of the huge draws of MCP servers was a reusable standard to describe tools, but if everyone re-implements their own tools, then where's the value?
I assume this comes from the fact that it is very easy to create an MCP server, it is much harder to create a good MCP server. And so, a number of companies have fallen into "not invented here" or they just want to be able to control the quality of the MCP servers (that's fair). a "GitHub MCP" is a dime-a-dozen but I wrote a lot of MCP servers just for myself because often the servers provided 80% of what I wanted. It's early days for MCP but it's been easier in all cases to just write my own MCP from scratch instead of trying to fork off something existing. I'm sure that will change as time goes on but MCP is, often, a thin layer over a SDK/API, it's not hard to implement.
All of this gets to an idea that I've been playing around in my head and and have written about a fourth of a blog post on, which is "MCP interfaces". MCP Interfaces, put very simply, is the concept of a pluggable way to swap out different MCP servers that may not implement the exact same tools, but are the same spirit of tools. So, for example, a way to plug in Google search, Bing search, SearXNG, or Jina.ai search.
Why do we even need "interfaces"? Well, throwing all the tools at every LLM is a recipe for disaster in multiple ways (privacy, security, sanity, the list goes on) and often agents work best with a limited set of tools they know how to best utilize. That's all well and good and I'm sure most SaaS' out there will write their own tools or pick off-the-shelf MCP servers but for the open source world I've been thinking it would be nice to slot in your own MCP tools for certain tasks.
Search is an easy example. Lots of tools can make use of search (other good examples might be headless/headed browser automation, or memory/RAG) and I've seen the trend of different LLM application asking for all sorts of ways to do search. Some ask for your Google API key, some want Jina, some want SearXNG (some want to spin up their own docker container for SearXNG). It's all over the place, it's inconsistent, and it's a ton of wasted work. I don't want to ask the developer of "insert cool LLM application" to support my special-snowflake MCP server or tool, but I also don't want to just throw additional tools at the agents.
So far the best I can come up with is "MCP Interface" where an application can have a "minimum viable" tool(s) definition and then you can slot in MCP tools that meet that standard. Maybe "Interface" is too strict even, maybe it would just work to say "Here are my search tools, use them wherever you would provide an agent with search features". "MCP Tagging"?
I'm not sure and in a year maybe we won't even be talking about MCP or maybe the world of plug and play will be tiny/non-existent so this idea will not matter. In a way it seems too utopian to imagine we'd end up in a place where a user can say "I have my own search, let's use that" and instead we will have MCP app stores inside SaaS products (with no overlap or use outside the SaaS in question), or maybe we won't even get that, you'll just get whatever the SaaS wrote or, more likely, got from the open source community.
Yes thank you for sharing your thoughts. The MCP interfaces definitely sound promising. However I think it does not stop people from building other MCP servers . And different people may have different opinions regarding how to design this interface for a search MCP server.
TBH I think all of these problems are still very new (remember MCP is only 6 months old) and I think we need to wait and see how things evolve.
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?
Yes thank you! the newest MCP spec added the authentication part but it seems that people think it is still not perfect and are doing more modifications to the auth part. E.g. https://github.com/modelcontextprotocol/modelcontextprotocol.... We will also keep an eye on the spec development.
> For example, will AWS (or insert any other hyperscaler) end up providing the “Bedrock” of MCP where security is native to the platform?
Cloudflare already provides something along those lines with MCP on Workers with authentication (via their zero trust product AFAIK): https://blog.cloudflare.com/remote-model-context-protocol-se...
Sounds like they were one of the partners with Anthropic in their recent “Integrations” announcement.
Looking great!
I'm actually actively looking for something like this. But I'm not sure it fulfills my requirements.
Here is what I'm looking for - curated open source MCP servers - trusted curator - direct oauth integration, so the user permission is taken over (e.g.: you login with your companies Microsoft account and not with the account of the AI-Client.) this is a must for enterprise - easy to ship (eg.: via electron app) - I as the developer or the company owner can decide what servers are available to the user, and what tools (e.g.: most companies I talk to want read only access for their employees)
If Klavia fulfills that I would like to have a chat :)
Hi yes it sounds like Klavis AI meets your requirement. Can you shoot me an email at xiangkaiz@klavis.ai? Happy to chat!
This looks great will definitely have a look. What I wish that there was also MCP client (SDK) for mobile devices either native (Swift / Kotlin ) or React Native / Expo ( ideally with integration with vercel ai sdk). For mobile dev this would simplify setup (not need to have a proxy server) and allow business models with end-user Bring-Your-Own-Key.
Thanks! I think our hosted version has an API endpoint satisfy your needs on mobile devices. You can use our API to call any remote MCP server tools directly. https://docs.klavis.ai/api-reference/mcp-server/call-tool.
Regarding SDKs, yes we are planning to add SDKs as well. The Vercel AI SDK is definitely an interesting one. I will take a look.
This looks like it would add nothing. MCP's were released like 2 seconds ago, if you want to build something in prod, you can build it against the official MCP code.
If you want to add something in the middle or a MCP specific dependency it should add some value, some specific value: industry specific, or add some specific feature.
This is just a generic dependency that provides overly generic features like "production ready" and "integration" (that's true for all dependencies.
Par for the course for AI companies, "do everything for everyone"
It's vibefrastructure. Vibe coders don't do prod-ready but they can lean on services like this. See also: vercel, firebase etc.
haha I like the word vibefrastructure!
This looks interesting! I'll be keeping an eye on it. A few questions that come to mind:
- Is there a way to run it locally/self-host?
- Are there discovery endpoints to list the available servers?
- The 'Test & Eval' page is interesting to me, as I think unpredictability of results with multiple MCP prompts/sources interacting is generally a pretty big issue with MCP, so a good integrated eval system could be valuable. I see it's not launched yet, but it would be great to know more about how this will work.
Agree on the unpredictability of results issue. Tool call selection is still sort of a black box.
How do you know what variations of a prompt trigger a given tool to be called or how many tools is too many before you start seeing degradation issues because of the context window. If you are building a client and not a server the issue becomes even more pronounced.
I even extracted the Claude electron source to see if I could figure out how they were doing it, but it's abstracted behind a network request. I'm guessing the system prompt handles tool call selection.
PS: I released an open source evals package if you're curious. Still a WIP, but does the basics https://github.com/mclenhard/mcp-evals
Thanks, I'll check it out.
I'm working on a coding agent, and MCP has been a frequently requested feature, but yeah this issue has been my main hesitation.
Getting even basic prompts that are designed to do one or two things to work reliably requires so much testing and iteration that I'm inherently pretty skeptical that "here are 10 community-contributed MCPs—choose the right one for the task" will have any hope of working reliably. Of course the benefits if it would work are very clear, so I'm keeping a close watch on it. Evals seem like a key piece of the puzzle, though you still might end up in combinatorial explosion territory by trying to test all the potential interactions with multiple MCPs. I could also see it getting very expensive to test this way.
I actually came across Plandex the other day. I haven't had the chance to play around with it yet, but it looked really cool.
But agree that even basic prompts can be a struggle. You often need to name the tool in the prompt to get things to work reliably, but that's an awful user experience. Tool call descriptions play a pretty vital role, but most MCP servers are severely lacking in this regard.
I hope this a result of everything being so new and the tooling and models will evolve to solve these issues over time.
Yeah, I'm still wondering if MCP will be the solution that sticks in the long run.
It has momentum and clearly a lot of folks are working on these shortcomings, so I could certainly see it becoming the de facto standard. But the issues we're talking about are pretty major ones that might need a more fundamental reimagining to address. Although it could also theoretically all be resolved by the models improving sufficiently, so who knows.
Also, cool to hear that you came across Plandex. Lmk what you think if you try it out!
Yes I agree with you. What are the major shortcomings that you can think of right now (especially the ones that we have not solved)?
I think the two biggest issues are probably:
1. Giving the model too many choices. If you have a lot of options (like a bunch of MCP servers) what you often see in practice is that it's like a dice roll which option is chosen, even if the best choice is pretty obvious to a human. This is even tough when you just have a single branch in the prompt where the model has to choose path A or B. It's hard to get it to choose intelligently vs. randomly.
2. Global scope. The prompts related to each MCP all get mixed together in the system prompt, along with the prompting for the tool that's integrating them. They can easily be modifying each other's behavior in unpredictable ways.
Makes sense. Both are hard problems I agree.
Even with proper tool call descriptions, I've had quite a few occasions where the LLM didn't know how to use the tool.
The tools provided by the MCP server were definitely in context and there were only two or three servers with a small amount of tools enabled.
It feels too model dependant at the moment, this was Gemini 2.5 Pro which is normally state of the art but has lots of quirks for tool use it seems.
Agreed on hoping models are going to be trained to be better at using MCP.
Right, my workflow to get even a basic prompt working consistently rarely involves fewer than like 10 cycles of [run it 10 times -> update the prompt extensively to knock out problems in the first step]
And then every time I try to add something new to the prompt, all the prompting for previously existing behavior often needs to be updated as well to account for the new stuff, even if it's in a totally separate 'branch' of the prompt flow/logic.
I'd anticipate that each individual MCP I wanted to add would require a similar process to ensure reliability.
> Is there a way to run it locally/self-host?
Yes our github page has README for all MCP servers and clients. You can checkout https://github.com/Klavis-AI/klavis.
> Are there discovery endpoints to list the available servers?
Yes. https://docs.klavis.ai/api-reference/mcp-server/get-all-serv.... And we are adding more MCP servers.
> Testing and Eval
Yes it is early access now. If you are interested, shoot me an email at xiangkaiz@klavis.ai and we can talk more.
Thanks! So the MCP stuff is open source but the directory/api is cloud only?
Yes that is correct.
Cool, that's fine with me, but my suggestion fwiw would be to make this crystal clear upfront so you don't risk people feeling misled.
I would also personally consider just open sourcing everything (or at least core features) as I think you'd still have plenty of customers who would prefer a hosted solution. In my experience, there is surprisingly little overlap between the people who prefer cloud vs. self-hosting, so having a full open source option doesn't cannibalize the product side as much as you might think... people who prefer cloud will mostly still prefer it even if they could self-host instead, and people who prefer self-hosting will generally just look for another project rather than using your cloud service. Just my unsolicited 2 cents.
Got it, thank you for sharing this. Yes I have updated the post so that it is more clear that there are two versions. Thank you for the feedback.
What is the UX for an end user with the OAuth? They use MCP say for GitHub in Cursor, how do they provide access to their GitHub?
Also why would they not just use the official GitHub MCP?
Hi yes so if you just use it yourselves locally in Cursor, I think you can definitely just use the official GitHub MCP. But there might be more use cases where people want to connect MCP servers in their AI agents and deploy it in the cloud, then the local GitHub server would not be a fit.
The UX for end user OAuth is the standard GitHub Oauth flow. You will see a webpage saying that an GitHub Oauth App is requesting access to your github and you need to select yes/no.
usually you pass an ENV var as args with the personal acccess token
yes right forgot to mention this.
If it's open source, why do I need an API key to get started? What does the API key do?
The API is for our hosted version. For open source, you can go to https://github.com/Klavis-AI/klavis and check the comprehensive readme. I think we have readme for every MCP server and client and how to set that up.
Step one of you read me in the repo you just mentioned says: ```Sign up for Klavis platform and create your API key```
Hi! Thank you for catching this! I have fixed it right away. This is valuable feedback and I really appreciate it. Now the quick start points to the list of readmes and the hosted version is in the second half of the readme with a clear section Hosted Solutions.
You're welcome and thank you for the update/answer
It’s a startup so there has to be some kind of monetisation right?
Does this mean that we'd have to store our various keys/credentials with you (in the hosted solution).
If so, I would emphasize or add more documentation on how you are securing credentials.
And how would I add this to my agent? Would you have One MCP To Rule Them All?
Yes thank you for the good feedback. We will update our doc to reflect this.
> how would I add this to my agent? Would you have One MCP To Rule Them All?
If you are talking about the hosted version, you can go to our website to grab an API key and call the corresponding endpoint. https://docs.klavis.ai/documentation/mcp-server/github is the doc for GitHub MCP server.
in terms of one mcp to rule them all, it is something on our roadmap now. We are thinking that you can connect to all of the MCP servers we provide with a single URL and you can turn on/off the MCP servers in a simple UI or through API call. Let me know if this is what you have in mind.
Right now, as you know we’re in a total Wild West with this. So the experience is different for each client (VS code, cursor, etc)
To me, the ideal the UX is similar to the extensions UXs in each IDE, you search, click install, and get on with your life after doing an OAuth dance. Or even a discovery mechanism built into the agent itself. Sort of a “have you considered installing this? I can talk directly to JIRA for you” etc
The next best thing would be a catalog where I search, and with a single install button that would add the MCP to a certain IDE. But do the IDEs make this sort of API available, given that they all want to differentiate?
I like from what I see and the option of self hosting. Does it have a middleware like feature to extend, say I want to add more apps than what is provided out of the box ?
Hi, you are definitely more than welcome to create PRs in our repo to add more MCP servers.
Honestly, feels like every time I look at this stuff, the basics like consistent auth and real standards are still kinda up in the air. I keep thinking the endless remixing happens because nobodys happy with defaults yet. You think well ever land on one real standard or is everyone just gonna keep rolling their own forever?
Hopefully, in the end we will all converge to the real standards. But I understand your concerns now and I agree that right now it is a bit messy.
Welcome to MCP hosting space guys. We’ve also been hosting MCPs since early Feb in https://supermachine.ai and investing a lot into open-source (see https://github.com/supercorp-ai/supergateway and many others).
Guess there’s gonna be more competition haha (but don’t worry, I think our approaches are a bit different).
Why is it so expensive? 100$ a month.
The interesting question is what are your respective end games and do they compete? By this I mean like Facebook was seemingly a face book for college campuses at first.
What is MCP?
MCP is a new protocol from anthropic to standardize sharing tools and context with LLMs. Before, the tool calling api from openai was standard but tool makers all built their own mechanisms for defining and sharing tools.
It's a bit of a stretch but MCP is to LLM enabled applications what REST is to web applications.
What was happening before was if you built tools using langchain, you'd have to rewrite them for crewai, cursor, etc. Now, we have a way to share tools, resources, and prompts with applications built using different frameworks.
https://www.anthropic.com/news/model-context-protocol
I've seen a number of projects re-implement the same MCP servers that exist elsewhere, and I wonder if we're doomed to do this over and over and over again. One of the huge draws of MCP servers was a reusable standard to describe tools, but if everyone re-implements their own tools, then where's the value?
I assume this comes from the fact that it is very easy to create an MCP server, it is much harder to create a good MCP server. And so, a number of companies have fallen into "not invented here" or they just want to be able to control the quality of the MCP servers (that's fair). a "GitHub MCP" is a dime-a-dozen but I wrote a lot of MCP servers just for myself because often the servers provided 80% of what I wanted. It's early days for MCP but it's been easier in all cases to just write my own MCP from scratch instead of trying to fork off something existing. I'm sure that will change as time goes on but MCP is, often, a thin layer over a SDK/API, it's not hard to implement.
All of this gets to an idea that I've been playing around in my head and and have written about a fourth of a blog post on, which is "MCP interfaces". MCP Interfaces, put very simply, is the concept of a pluggable way to swap out different MCP servers that may not implement the exact same tools, but are the same spirit of tools. So, for example, a way to plug in Google search, Bing search, SearXNG, or Jina.ai search.
Why do we even need "interfaces"? Well, throwing all the tools at every LLM is a recipe for disaster in multiple ways (privacy, security, sanity, the list goes on) and often agents work best with a limited set of tools they know how to best utilize. That's all well and good and I'm sure most SaaS' out there will write their own tools or pick off-the-shelf MCP servers but for the open source world I've been thinking it would be nice to slot in your own MCP tools for certain tasks.
Search is an easy example. Lots of tools can make use of search (other good examples might be headless/headed browser automation, or memory/RAG) and I've seen the trend of different LLM application asking for all sorts of ways to do search. Some ask for your Google API key, some want Jina, some want SearXNG (some want to spin up their own docker container for SearXNG). It's all over the place, it's inconsistent, and it's a ton of wasted work. I don't want to ask the developer of "insert cool LLM application" to support my special-snowflake MCP server or tool, but I also don't want to just throw additional tools at the agents.
So far the best I can come up with is "MCP Interface" where an application can have a "minimum viable" tool(s) definition and then you can slot in MCP tools that meet that standard. Maybe "Interface" is too strict even, maybe it would just work to say "Here are my search tools, use them wherever you would provide an agent with search features". "MCP Tagging"?
I'm not sure and in a year maybe we won't even be talking about MCP or maybe the world of plug and play will be tiny/non-existent so this idea will not matter. In a way it seems too utopian to imagine we'd end up in a place where a user can say "I have my own search, let's use that" and instead we will have MCP app stores inside SaaS products (with no overlap or use outside the SaaS in question), or maybe we won't even get that, you'll just get whatever the SaaS wrote or, more likely, got from the open source community.
Yes thank you for sharing your thoughts. The MCP interfaces definitely sound promising. However I think it does not stop people from building other MCP servers . And different people may have different opinions regarding how to design this interface for a search MCP server.
TBH I think all of these problems are still very new (remember MCP is only 6 months old) and I think we need to wait and see how things evolve.