Below, I describe how an AI Agent\/LLM decides whether to call an MCP Tool, which<\/em> tool to call, and when not<\/em> to call one.<\/p>\n\n\n\n MCP (Model Context Protocol<\/a>) is designed so that external Tools can become part of the LLM\u2019s (Large Language Model<\/a>) decision-making environment. But note that the LLM doesn\u2019t run<\/em><\/strong> tools on its own \u2014 it selects<\/em><\/strong> Tools based on the conversation context, various Tool schemas, and the LLM\u2019s own internal decision heuristics.<\/p>\n\n\n\n The following mental model explains how it works.<\/p>\n\n\n\n The term “MCP Tool contract” refers to the MCP specification<\/a> that defines how AI Agents communicate with external Tools and services. This protocol standardizes the interaction, acting as a universal interface between LLMs and the functions they can call to perform actions or access data. <\/p>\n\n\n\n This contract is the schema and metadata that describe a Tool’s capabilities, inputs, and expected outputs.<\/p>\n\n\n\n Every MCP Tool provides a definition structure that contains:<\/p>\n\n\n\n In this article, I will defer discussing detailed aspects involving vector representations (embeddings), named entity recognition (NER), etc. But at a high level, it is essential to understand that the Agent ingests the Tool\u2019s definition structure, and then the LLM forms a semantic<\/em><\/strong> <\/em>signature<\/em><\/strong> <\/em>that <\/em>represents the Tool.<\/p>\n\n\n\n When Agents connect to an MCP server, the Tools metadata \u2014 an array with names, parameter schemas, descriptions, etc. \u2014 becomes vectorized<\/strong> inside the LLM. This produces an internal “tool embedding” for each Tool.<\/p>\n\n\n\n Later, during NLP operations (input prompts from the user to the Agent), the LLM uses this semantic signature embedding to infer:<\/p>\n\n\n\n This is why high-quality Tool names, descriptions, and parameter descriptions matter so much when building MCP Tools.<\/p>\n\n\n\n Tool descriptions are not procedural instructions. They become semantic memories<\/strong> that the LLM embeds and can later compare against natural language. <\/p>\n\n\n\n Without embeddings, the LLM\u2026<\/p>\n\n\n\n Embeddings make Tool utilization a meaning- or intent-matching <\/strong>task, not a keyword-matching<\/strong> task.<\/p>\n\n\n\n LLMs store tool descriptions as dense semantic vectors, then compare the vectorized user prompt against these internal \u201ctool embeddings\u201d to decide if<\/strong> a tool should be invoked, which one<\/strong>, and how<\/strong> to populate its parameters.<\/p>\n\n\n\n Based on the user’s latest message, the LLM internally performs an intent classification step (not externally visible to the user). Essentially, the LLM asks itself:<\/p>\n\n\n\n Tools are only chosen if:<\/p>\n\n\n\n The LLM tends to be conservative: if it can answer without a tool, it will.<\/p>\n\n\n\n Again, internally, it reasons out something like: \u201cGiven the user\u2019s intent, which available tools appear relevant?\u201d<\/p>\n\n\n\n For each tool, it checks:<\/p>\n\n\n\n This amounts to semantic similarity search + heuristics, not code execution<\/em><\/strong>.<\/p>\n\n\n\n This is an important subtlety.<\/p>\n\n\n\n The LLM doesn\u2019t run<\/em> the tool or simulate its output before choosing it. It predicts the next token<\/em>, which happens to be a JSON object that the Agent framework interprets as a tool call.<\/p>\n\n\n\n If the next-token probability distribution supports a tool invocation pattern, you will see a tool call.<\/p>\n\n\n\n So the LLM isn\u2019t \u201cdeciding\u201d in the human sense \u2014 it\u2019s predicting tool-call tokens when they appear appropriate, given the prompt, chat history, tool descriptions, and system guidelines.<\/p>\n\n\n\n Depending on the agent framework (Anthropic\u2019s, OpenAI\u2019s, LangChain, or even your own custom MCP runner):<\/p>\n\n\n\n These meta-rules significantly affect tool selection.<\/p>\n\n\n\n Note that the MCP server NEVER sends a system prompt. The MCP server only provides:<\/p>\n\n\n\n But the MCP server never<\/strong> includes actual pre-instructions for the LLM.<\/p>\n\n\n\n This is intentional.<\/p>\n\n\n\n The system prompt must come from the client<\/em> who is orchestrating the conversation. Let\u2019s use the Claude Desktop Agent as an example of an MCP client. <\/p>\n\n\n\n When you add an MCP server to Claude Desktop, the sequence looks like:<\/p>\n\n\n\n You cannot change the system prompt in Claude Desktop today. The client controls it, not the tool server.<\/p>\n\n\n\n If you build your own agent using, say, the official Node SDK (@modelcontextprotocol\/sdk), you can certainly provide your own system prompt.<\/p>\n\n\n\n Example:<\/p>\n\n\n\n Here, you, as the developer, decide the system prompt.<\/p>\n\n\n\n This is exactly what Agents like ChatGPT and Claude Desktop do behind the scenes. The model avoids tools in these cases:<\/p>\n\n\n\n The more carefully you write:<\/p>\n\n\n\n \u2026the more likely the model will correctly choose them. <\/p>\n\n\n\n Good Tools feel like natural language functions<\/em>. <\/p>\n\n\n\n Bad Tools feel like weird API endpoints the model tries to avoid.<\/p>\n\n\n\n Bad:<\/p>\n\n\n\n Good:<\/p>\n\n\n\n Bad:<\/p>\n\n\n\n \u201cThis tool queries the backend.\u201d<\/p>\n\n\n\n Good:<\/p>\n\n\n\n \u201cUse this tool whenever the user wants to look up the details of a specific identity in Ziti by ID or name.\u201d<\/p>\n\n\n\n Examples:<\/p>\n\n\n\n Don\u2019t use:<\/p>\n\n\n\n \u201cDoes something with deployments.\u201d<\/p>\n\n\n\n Do use:<\/p>\n\n\n\n \u201cReturns full deployment metadata including version, manifest, dependencies, and status, for auditing or debugging.\u201d<\/p>\n\n\n\n Bad:<\/p>\n\n\n\n { “id”: “string” }<\/p>\n\n\n\n Good:<\/p>\n\n\n\n { “identity_id”: “The Ziti identity ID (uuid) to look up.” }<\/p>\n\n\n\n LLMs can struggle with:<\/p>\n\n\n\n If possible:<\/p>\n\n\n\n Example fields are very<\/em> influential.<\/p>\n\n\n\n Great<\/strong><\/p>\n\n\n\n “createUser”: {<\/p>\n\n\n\n “description”: “Create a new user record. Use this when the user asks to register, sign up, or create an account. Requires a unique email.”,<\/p>\n\n\n\n “parameters”: { … }<\/p>\n\n\n\n }<\/p>\n\n\n\n Why it works:<\/p>\n\n\n\n Bad<\/strong><\/p>\n\n\n\n “createUser”: {<\/p>\n\n\n\n “description”: “User tool for accounts.”,<\/p>\n\n\n\n “parameters”: { … }<\/p>\n\n\n\n }<\/p>\n\n\n\n Why it fails:<\/p>\n\n\n\n I learned most of what is discussed above while building some MCP Server prototypes related to some AI functionality that NetFoundry will be rolling out soon.<\/p>\n\n\n\n To illustrate what can go wrong if you haphazardly design your Tools, I will show you some real examples, using the Claude Desktop Agent as the client. <\/p>\n\n\n\n I will demonstrate some internal Tool definitions used in an early prototype of an OpenZiti MCP Server, capable of being embedded within the Claude Desktop AI Agent.<\/p>\n\n\n\n NOTE: This OpenZiti MCP Server is intended to enable the use of natural language for managing a Ziti network. Yes, you heard that correctly… soon, you will be able to type ordinary human language queries or commands into Claude, and those operations will execute against your selected OpenZiti network. More on this below…<\/em><\/p>\n<\/blockquote>\n\n\n\n Here is an admittedly contrived, very badly written (and perhaps tortured)<\/em> Tool definition:<\/p>\n\n\n\n This Tool has no mention of Ziti or any Ziti constructs (such as Identities).<\/p>\n\n\n\n Let\u2019s find out what happens in Claude if I attempt to accomplish something related to a Ziti network, such as getting a list of existing Identities. <\/p>\n\n\n\n By the way, it is worth noting that the my_tool<\/strong> Tool in this silly example is actually wired up with a function that can securely access the Ziti Controller\u2019s management API and fetch Identities (the details of which are a topic I will discuss in an upcoming article<\/em>). So, if the Claude Desktop Agent somehow made the association between a user prompt and this my_tool <\/strong>Tool, then Identity information would indeed be fetched from the Ziti Controller\u2019s management API and returned to Claude.<\/p>\n\n\n\n OK, once my MCP Server and its Tools are installed in Claude Desktop, I can enter the prompt:<\/p>\n\n\n\n \u201c<\/em><\/strong>can you help me determine what identities exist in the network?<\/em><\/strong>\u201d<\/em><\/strong><\/p>\n\n\n\n Claude ponders<\/em> for quite a while, then gives up and says this:<\/p>\n\n\n\n It is abundantly clear that the Claude Desktop Agent (the MCP client) did not have the necessary data (i.e., the proper vector embeddings) to associate the semantics<\/em><\/strong> contained in the prompt with a Tool capable of carrying out the task.<\/p>\n\n\n\n Claude had no notion of Ziti networks at all, let alone how to obtain a list of Identities that exist in the network. This is not a surprise, given how poorly the contrived Tool definition was written.<\/p>\n\n\n\n Now, let’s craft a good Tool definition. <\/p>\n\n\n\n We\u2019ll replace the contrived example shown above with a proper one that adheres to best practices concerning Tool definition. We\u2019ll give it a very detailed description, and a name that makes it obvious to the LLM what the Tool is intended for:<\/p>\n\n\n\n Now watch what happens in Claude after I reinstall my MCP server with this Tool definition, and I then attempt to accomplish the same task of listing existing Identities.<\/p>\n\n\n\n When I re-enter the same prompt: <\/p>\n\n\n\n \u201c<\/em><\/strong>can you help me determine what identities exist in the network?<\/em><\/strong>\u201d<\/em><\/strong><\/p>\n\n\n\n Claude now says this:<\/p>\n\n\n\n Success!<\/p>\n\n\n\n As you can see, since the Agent was provided a proper Tool definition, the LLM was allowed to generate proper embeddings for the Tool, then use the embeddings to understand the semantic meaning <\/strong>of the <\/strong>prompt, then associate that meaning with the appropriate Tool, and finally send a request to the Tool best suited to carry out the task.<\/p>\n\n\n\n Conclusion<\/strong><\/p>\n\n\n\n The OpenZiti MCP Server highlighted in the DEMO section above is capable of being embedded within Claude Desktop, so you can also use natural language to manage your Ziti network.<\/p>\n\n\n\n What\u2019s also exciting is that this OpenZiti MCP Server is also capable of being embedded into the many AI Coding Agents available today (e.g., Cursor<\/a>, Windsurf<\/a>, VSCode<\/a>). This will allow developers to integrate OpenZiti SDKs into their applications much more quickly and easily (watch for upcoming articles on that).<\/p>\n\n\n\n As an engineer at NetFoundry, I am involved in crafting OpenZiti and related technologies, such as the OpenZiti MCP Server you saw glimpses of above.<\/p>\n\n\n\n If using natural language to manage your Ziti network sounds interesting to you, please use this form to express your interest.<\/strong><\/a> We are wrapping up the initial version of this MCP server, and you can be among the first to try out the beta\u2026so be sure to get on the list.<\/p>\n\n\n\nHow an LLM Decides to Call MCP Tools<\/strong><\/h2>\n\n\n\n
The LLM sees each Tool as a function with a \u201ccontract\u201d<\/strong><\/h3>\n\n\n\n
\n
\n
\n
The LLM maps user intent \u2192 candidate tool(s)<\/strong><\/h3>\n\n\n\n
\n
<\/li>\n<\/ul>\n\n\n\n\n
The LLM evaluates all tools against the current query<\/strong><\/h3>\n\n\n\n
\n
The LLM predicts the tool call <\/strong>as text<\/em><\/strong>, not by executing logic<\/strong><\/h3>\n\n\n\n
The hosting Agent may also influence the decision<\/strong><\/h2>\n\n\n\n
\n
\n
<\/li>\n<\/ul>\n\n\n\n\n
![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-1019x1024.jpg\")
<\/figure>\n\n\n\nHow the System Prompt and Tool Descriptions Merge<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-1.jpg\")
<\/figure>\n\n\n\n
<\/p>\n\n\n\nWhen the model decides <\/strong>not<\/em><\/strong> to call a tool<\/strong><\/h2>\n\n\n\n
\n
Models also learn from prior tool calls in the conversation<\/strong><\/h2>\n\n\n\n
\n
Designing Tools the LLM Will Actually Use<\/strong><\/h2>\n\n\n\n
Use a strong, unambiguous, action-oriented tool name<\/strong><\/h3>\n\n\n\n
\n
\n
<\/li>\n<\/ul>\n\n\n\nDescription should be one short paragraph telling the model exactly when to use it<\/strong><\/h3>\n\n\n\n
Include natural-language cues that the model will remember<\/strong><\/h3>\n\n\n\n
\n
Tool descriptions should not be vague<\/strong><\/h3>\n\n\n\n
Parameter names should be obvious and self-explanatory<\/strong><\/h3>\n\n\n\n
Avoid deeply nested schemas<\/strong><\/h3>\n\n\n\n
\n
<\/li>\n<\/ul>\n\n\n\n\n
Use examples when possible<\/strong><\/h3>\n\n\n\n
Examples of GREAT vs. BAD tool descriptions<\/strong><\/h2>\n\n\n\n
\n
<\/li>\n<\/ul>\n\n\n\n\n
<\/li>\n<\/ul>\n\n\n\nDEMO<\/strong><\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-2.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-3.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-4-1024x605.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/netfoundry.io\/wp-content\/uploads\/2025\/11\/ts-5-947x1024.jpg\")
<\/figure>\n\n\n\n