I don't know how that is solved by MCP? How would the LLM possibly know where to search? Just making an API (or series of APIs) to slack/jira/airtable available doesn't magically surface the context, or the right search incantation to reveal it. The LLM still has to figure out which tool to search within, what search terms/tools are the right ones to choose, etc. If there are a million documents in your set of data providers and only 1000 fit into the context of the LLM, that filter happens somewhere.

This idea that if you don't know where the data is, magically the LLM will, is very confusing to me.

In my experience, this kind of thing is exactly what LLMs are good at, and fast at.

Here's a real example from my job as a BI dev. I needed to figure out how to get counts of incoming products from an ERP with a 1000+ table database schema in a data lake with 0 actual foreign keys. I sorta knew the data would need to come from the large set of "stock movements" tables, which I didn't know how to join, and I had no idea which rows from that table would be relevant to incoming product or even which fields to look at to even begin to determine that. I simultaneously asked a consultant for the ERP how to do it and asked Cursor a very basic "add the count of incoming units to this query" request.

Cursor gave me a plausible answer instantly, but I wasn't sure it was correct. When the consultant got back to be a few days later, the answer he gave was identical to Cursor's code. Cursor even thought of an edge case that the consultant hadn't.

It blew my mind! I don't know if Cursor just knows about this ERP's code or what, or if it ran enough research queries to figure it out. But it got it right. The only context I provided was the query I wanted to add the count to and the name of the ERP.

So, I 100% believe that, especially with something like MCP, the pull model is the right way. Let the LLM do the hard work of finding all the context.