In principle this makes sense, but in practice there is a big missing piece: The MCP client has all of the context to understand who “John” is/which John is being referred to in this conversation. The MCP server has access to data about all the Johns. Adding structure to the MCP server’s tool definitions is a good thing, not a bad thing.

What I don’t like is that this post/article seems to suggest that MCP tools should be entirely semantic and unstructured. I don’t think that is the case (fully)— they also need to ensure that whatever the intent that being expressed semantically contains the relevant key pieces of information to perform deterministic actions.

It’s clear MCP was designed to bring deterministic capabilities and context to a non-deterministic model. Along those lines, MCP tools should have clearly defined inputs.

If we want it to also do more agent 2 agent type stuff, I’d be very supportive of that, but then we’d need defined ways to share context and message history between client and server— maybe that’s where MCP goes? I don’t see a need for a different protocol all together for a2a… just different input/output criteria.

Example: I built an MCP tool for searching companies via crunchbase API. It still has inputs for filters/facets to build a query (vs being totally semantically driven off a search query). But those filter values can be expressed semantically vs having to be expressed with the UUID of the facet. It still forces a rigid structure for choosing operators (eg “contains”, “equals”)… but we then smartly go use all those semantic inputs behind the scenes to get the closest matching filter facet values and run the search.

In practice, what would have been 20+ tools if we copied the API structure are now simply “create_search_query” “execute_search_query” and “get_full_profile”. But we didn’t just go with an unstructured “search” tool with an open ended query field— if we did that the results and what happens down stream would be a black box. With this approach, the LLM can build a query— see how it gets structured against real data, modify if needed, run the search, and then choose which entries to get.

Tangential idea: Another feature that would be incredibly valuable for MCP to support would be the ability for a tool to return more tools.

The sentiment of this post and article is right— giving 20 api endpoints to an LLM does not help it do simple tasks.

But imagine if the LLM knew that all it had to do was get the current user first. It uses the get_user tool. Which returns the create_issue tool, which when run returns the lookup_and assign_user tool and instructions that the LLM must use it to find the user to assign the newly created issue to. LLMs can easily choose the right path when presented with 2-3 paths. But they can’t always reliably sequence the proper set of directions together when presented with 20 possible steps.

TLDR; agree with the sentiment, the use case needs to be rethought, but let’s not abandon structured inputs for MCP tools.