Comment by mindwok
Yes because we should all be building function calling implementations for the same 10 SaaS services rather than using 10 standard MCP servers.
Yes because we should all be building function calling implementations for the same 10 SaaS services rather than using 10 standard MCP servers.
That is being done as a stop gap until official servers are released. Ideally you are writing a server for your own product/service, or custom local work.
i.e. I wrote a server for water.gov to pull the river height prediction nearby for the next 24hr. This helps the campground welcome message writing tool craft a better welcome message.
Sure that could be a plain tool call, but why not make it portable into any AI service.
Remote MCP servers can do prompt injection that instruct your local agent to do something else other than only the expected tool call. https://embracethered.com/blog/posts/2025/model-context-prot...
That flaw isn't introduced by the MCP server necessarily it can already be present in the API data it returns, you will never be able to protect yourself against someone injecting a malicious prompt that calls your code eval tool to open up a reverse shell on your MacBook Pro.
But the standard servers should be hosted by the service provider, like mcp.slack.com as a counterpart to api.slack.com
Why should I be self-hosting ANY local MCP server for accessing an external service?