This is 100% a problem with the MCP spec: it does not currently provide a way to narrow what tools, and therefore context, flow into the LLM.

I don't really think there's an easy solution at the protocol level, since you can't just make the LLM say what tools it wants upfront. There's a whole discovery process during the handshake:

LLM(Host): Hi, I'm Claude Desktop, what do you offer?

MCP Server: Hi, I'm Salesforce MCP, I offer all these things: {...tools, prompts, resources, etc.}

Discoverability is one of the reasons MCP has a leg up on traditional APIs. (Sure, OpenAPI helps, but it's not quite the same thing.)

I'd be interested in hearing other recommendations or ideas, but when I saw this, I realized that the spec effectively necessitates a whole new layer exist: the gateway plane.

Basically, you need a place where the MCPs can connect & expose everything they offer. Then, via composability and settings, you can select what you want to pass through to the LLM (host), given the specific job it has.

I basically pivoted my company to start building one of these, and we're getting inundated right now.

This whole thing reminds me of the early web days, where the protocols and standards were super basic and loose, and we all just built systems and tools to fill those gaps. Just because MCP isn't "complete" doesn't mean it's not valuable. In fact, I think leaving some things to the community & commercial offerings is a great way for this tech to keep winning.

> This is 100% a problem with the MCP spec: it does not currently provide a way to narrow what tools, and therefore context, flow into the LLM.

it's not the business of MCP spec, it should be task/job level, different task may need different tools and MCP just supply entire tools it has. The tool pickup should be the take charge by llm. moreover maybe some has `while list` to include or exclude some tools, but it should not from MCP spec.

> This is 100% a problem with the MCP spec

No, its not.

It’s a problem with the design of agentic workflows. Its on a whole different level of the atack than the MCP spec.

It is a real issue, but not one that it makes sense tor the MCP spec to be concerned with.

> OpenAPI helps, but it's not quite the same thing

I haven't dug into MCP yet, but can you give any examples as to why openapi isn't/wasn't enough?