> 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.