[pscanf]

I see MCP as fundamentally limited: even if we had an LLM that knew how to use it perfectly, at the end of the day MCP workflows are integrations between many different APIs that were not designed to be composed and to work together.

What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?

[JumpCrisscross]

> What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?

Aren’t these situations current models are quite good at?

[kingstnap]

No but mainly because passing actual data through the context is janky and expensive. So it's only useful as a one of at most.

This whole idea of doing unsupervised and unstructured work with unstructured data at scale with some sort of army of agents or something sounds ridiculous to me anyway. No amount of MCP or prompting or whatever is going to solve it.

Like if interesting problems are on the boundry of obvious and chaotic this is just like some janky thing that's way too far into the chaotic regime. You won't go anywhere unless you magically solve the value function problem here.

[PantaloonFlames]

If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.

About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.

[pscanf]

> If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.

I didn't explain myself very well, sorry. What I had in mind is: MCP is about putting together workflows using tools from different, independent sources. But since the various tools are not designed to be composed, scenarios occur in which in theory you could string together $TOOL_Y and $TOOL_X, but $TOOL_Y only exposes $DATA_SUBSET (because it doesn't know about $TOOL_X), while $TOOL_X needs $DATA. So the capability would be there if only the tools were designed to be composed.

Of course, that's also the very strength of MCP: it allows you to compose independent tools that were not designed to be composed. So it's a powerful approach, but inherently limited.

> About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.

Yes, distributed transactions / sagas / etc. Which are basically impossible to do with "random" APIs not designed for them.