Have a look at the Filesystem example MCP server - https://github.com/modelcontextprotocol/servers/blob/main/sr.... It has a collection of Tools - read_file, read_multiple_files, write_file, etc.
The LLM uses MCP to learn what tools the server makes available; the LLM decides when to use them. (The process is a little more complicated than that, but if you're just trying to call tools without an LLM, those parts aren't really important.) If you ask the LLM, "Find all files with an asterisk," it might deduce that it can use the search_files tool provided by that MCP to gain the needed context, invoke that tool, then process the results it returns. As an engineer, you can just call search_files if you know that's what you want.
The thing that surprises me is with MCP we have shirked all of the existing tools around OpenAPI specs, OIDC, etc. We could have created a system where all 'services' expose a mcp.slack.com/definition endpoint or something that spit back a list of shortcut terms like send_message and a translation function that composes it into the correct HTTP API (what most MCP servers do). For security we could have had the LLM establish its identity via all our existing systems like OIDC that combine authentication and authorization.
In the system above you would not "install an mcp package" as in a code repo or server. Instead you would allow your LLM to access slack, it would then prompt you to login via OIDC and establish your identity and access level. Then it would grab the OpenAPI spec (machine readable) and the LLM focused shortcuts 'send_message', 'read_message', etc. LLM composes 'send_message Hello World' -> translates to HTTP POST slack.com/message or whatever and bob's your uncle.
If you wanted to do fancy stuff with local systems then you could still build your own server the same way we have all built HTTP servers for decades and just expose the mcp.whatever.com subdomain for discovery. Then skip OIDC or allow ALL or something to simplify if you want.
The MCP exposed API is there for anyone/anything to use, as long as you are able to understand how it works - by reading the natural language description of the exposed methods and their JSON input schemas. You could read this yourself and then use these methods in any way you choose.
Where LLMs come in is that they understand natural language, so in the case where the MCP client is an LLM, then there is automatic discovery and integration - you don't need to grok the MCP interface and integrate it into your application, but instead the LLM can automatically use it based on the interface description.
But… you don’t really need to pretend you’re an LLM, you can just get the data using the same interface as a model would.
"Okay but. But. What if you just... removed the AI part?
What if it's just "a standardized way to connect literally anything to different data sources and tools"?"
(which had struck out text 'AI models' in between 'connect' and 'literally')