How AI Agents Discover and Execute MCP Tools: an Enterprise Guide

MCP (Model Context Protocol) tools are executable functions exposed by an MCP server so that an AI agent can discover them, choose one, pass structured arguments, and request an action. Each tool is defined by a name, a description, and an input schema, usually expressed with JSON Schema.

When your agent moves from chat to execution, the tool list becomes part of the architecture. But while a short list helps the model choose, a long registry of CRM, ERP, finance, and ordering actions can lead to suboptimal choices, inflate token use, and push the agent toward the wrong function.

Yet in an enterprise setting, a single request is rarely one tool call, often involving things like reading a source record, matching objects, validating fields, checking permissions, writing to a system of record, and handling errors without creating duplicates. Today, we’ll share with you everything you need to know to keep that tool list nice and focused so that your agents can do reliable work at scale.

Key Takeaways

• MCP tools are functions on a server that an AI agent can call, each with a name, a description, and an input schema that defines what to send it.
• An agent first asks a server which tools exist with tools/list, then runs the one it picks with tools/call.
• Long tool lists eat up context window space, raise token costs, and make the agent more likely to pick the wrong tool.
• Because enterprise actions change real systems of record, they need scoped tools, safe repeatable writes, and a clear audit trail.
• Engini works as an execution layer by showing each agent only the tools that fit the request.

Defining MCP Tools and Their Architecture

An MCP tool is a callable capability exposed by an MCP server. In the Model Context Protocol specification, tools are “model controlled,” meaning the client exposes them to an AI model, and the model then decides when to call them.

An MCP tool usually has three core parts – the table below breaks down each one.

For example, a Salesforce update tool should not rely on a vague description like “update record.” The agent instead needs enough detail to distinguish an account update from an opportunity update, a field patch, or a status transition.

The input schema also needs to be specific. A tool that updates a customer record may need a record identifier, allowed fields, expected types, and validation constraints. JSON Schema gives the tool a structured contract, so the AI client can understand the parameters before it submits a call.

The MCP specification also supports tool annotations and structured outputs where implemented. We recommend treating these as execution metadata because they help shape execution, but they don't replace clear tool naming or a precise schema.

What Goes Into a Good Tool Definition?

An executable function is useful to an AI agent only when the tool description and schema give the model enough signal to choose it correctly.

A clear tool definition answers four questions for the agent:

• What action does this tool perform?
• Which system or object does it act on?
• What input parameters are required?
• What output should the caller expect?

The name should be stable and specific – for instance, “update_salesforce_opportunity_stage” gives the agent more signal than “update_record.” In other words, the description should state the intended use case instead of repeating the name in longer words.

The input schema should in turn define required fields, optional fields, accepted types, and constraints. Those contracts are written in JSON Schema, which gives the agent a precise vocabulary for what it can send. Structured outputs can also help when the next step depends on machine-readable results. For example, an update tool can return a status, record ID, validation message, and timestamp. That makes downstream routing easier than parsing a natural language result.

However, a clean schema does not solve scale by itself. One good tool is easy for a model to evaluate, but hundreds of similar tools can create a different problem, because the model must compare descriptions and schemas inside its context window.

How AI Agents Discover and Execute MCP Tools

AI agents typically use MCP tools in two phases. First, the AI client asks the MCP server which tools are available. Then, it calls the selected tool with structured arguments. Those two steps are handled by "tools/list" and "tools/call."

A simple MCP flow looks like this:

1. The AI client connects to an MCP server.
2. The client requests available tools through "tools/list."
3. The server returns tool definitions, including names, descriptions, and input schemas.
4. The agent evaluates the tool list in its context window.
5. The agent selects a tool and prepares arguments.
6. The client sends a "tools/call" request.
7. The server runs the function and returns the result.

Note: That pattern works well when the tool registry is small and clear, but it becomes harder when enterprise systems expose hundreds of API endpoints, object actions, and role-specific operations.

Discovering Available Tools with "Tools/list"

"Tools/list" is the discovery step whereby the AI client requests the tool registry from the MCP server, and the server then returns the Model Context Protocol tools it can expose.

At a small scale, this is straightforward. A developer tool server might expose a few functions, such as reading a file, searching a repository, or creating a ticket. The LLM can then evaluate those descriptions and pick the right function.

For enterprise systems though, the setup is completely different. A CRM can expose actions for accounts, contacts, opportunities, cases, tasks, custom objects, field updates, queries, and relationship traversal. Similarly, an ERP can add orders, invoices, vendors, items, tax records, subsidiaries, and approvals.

That doesn't mean every endpoint should become visible to the model at once. "Tools/list" tells the agent what is available, but the architecture still needs to decide what should be visible for this user, this task, this environment, and this moment.

Large registries also bring operational details to handle, such as pagination when the tool list is long, or stateful tools when a call depends on prior context, session state, or a multi-step transaction.

Executing a Tool with "tools/call"

"tools/call" is the execution step. Here, the AI client sends a request to call one tool, with arguments that match the tool’s input schema. Under the hood, MCP sends these requests and responses as JSON-RPC messages – the standard format it uses for all client and server communication.

A successful "tools/call," however, needs more than a syntactically sound payload. The selected function must also match the user’s intent, the input parameters have to fit the schema, and the connected system has to accept the action.

For enterprise writes, that means the execution path may need:

• Authentication to the target system.
• Authorization for the requested action.
• Object and field validation.
• Duplicate checks and idempotency.
• Error handling when the destination rejects the write.
• A record of what happened for audit review.

Consider an agent asked to update a Salesforce opportunity stage. The right tool may need a specific opportunity ID, an allowed stage value, and scoped permission to modify that object. If the agent chooses a generic record update tool, it may pass the wrong arguments or target the wrong object.

That is why tool selection is part of execution architecture. A model can call tools, but the system around the model has to limit ambiguity before the call can reach a system of record.

Common MCP Servers and Enterprise Use Cases

MCP servers expose tools to AI clients. For example, a server can represent a local developer environment, a database, a SaaS application, or a governed path into a system of record.

The table below lays out each part of this setup and what it means for enterprises.

Developer Workflows

In developer workflows, MCP servers often expose file operations, code search, browser actions, database queries, and issue tracking. These work well because the tool set is small and the cost of a wrong call usually shows up fast.

Enterprise Workflows

Enterprise use cases need tighter design. A system integration flow may connect Salesforce to Oracle NetSuite, SAP Business One, SAP S/4HANA, or Oracle Fusion. The agent may then need to read from one system, enrich the request, and write to another system of record.

A simple example is a CRM update. If an agent is asked to update a Salesforce account, it should not receive every Salesforce action but instead get a scoped tool with the right object, fields, required arguments, and permission boundary.

For ERP workflows, the stakes are even higher, since creating a sales order, posting an invoice, or updating a vendor record can affect finance, inventory, and downstream reporting. So, while the MCP can expose the callable function, it does not decide the business control model on its own.

Matching the Setup to the Task

Native features or a standalone MCP server can typically be enough for single-system workflows. If the task stays inside one application, and the permission model is clear, a focused server may be the right shape.

In that sense, traditional middleware / iPaaS remains useful for deterministic system integration, especially when the workflow is known in advance and does not require agent-level tool selection. Citizen developers may also build focused automations for bounded tasks, but system-of-record workflows still need clear ownership for permissions, monitoring, and error handling.

Cross-system execution, however, adds more work. With this one, you need routing, policy, auditability, error handling, and consistent monitoring across every system the agent touches.

When Long Tool Lists Get in the Way

A long tool list is more than a prompt-size issue as it also changes how the model evaluates the task.

This is because the agent chooses from the tools it can see. Each tool name, description, and input schema takes context window space. As the list grows, the model has to then compare more similar options before choosing one.

That creates a direct tradeoff. Enterprise systems require broad coverage, but LLMs perform better when the relevant action space is narrow.

How Long Tool Lists Strain the Model

The context window contains the user request, system instructions, conversation history, available tool definitions, and any retrieved data. Tool schemas, on the other hand, compete with everything else the model needs to reason well.

Token bloat starts when the model receives too many tool definitions. But the cost isn't only larger requests as the agent may also have less effective room for the business context that tells it which tool is correct.

And so, when context degrades, it immediately shows up in the agent's behavior in one of the following ways:

• The agent chooses a similar, but wrong tool.
• The agent passes arguments that fit a different schema.
• The agent ignores a required parameter.
• The agent confuses read tools with write tools.
• The agent reaches token limits before it has enough business context.

Hallucinations can also increase when descriptions overlap. If the registry includes “update_customer,” “patch_customer,” “upsert_account,” and “modify_business_partner,” the model may infer capabilities that the selected tool does not actually support.

Note: A failed selection can look like a bad prompt when the real issue is that the architecture asked the model to sort through too much.

Why Exposing Every API Endpoint Isn't the Best Approach

A common early pattern is to expose raw enterprise API endpoints directly as tools. That can work in a small proof of concept, but it tends to break down when the agent reaches the CRM or ERP scale.

This is because raw endpoint exposure creates tool sprawl. In other words, the agent sees separate operations for objects, subrecords, searches, patches, creates, deletes, and custom fields. The list grows again when you add multiple systems, environments, roles, and object variants.

Dynamic filtering is a common solution here. Instead of sending every possible tool through "tools/list," the execution layer narrows the visible set based on the user request, identity, task context, and connected systems. However, that filtering should happen before tool selection and not after a failed write. Once the wrong function is selected, the system then has to catch schema errors, permission failures, destination validation errors, or duplicate writes.

For stateful enterprise workflows, the issue becomes even more pronounced. For example, a sales order write may depend on customer matching, item lookup, tax logic, subsidiary context, and an idempotency key. Exposing each low-level endpoint to the model then forces the agent to assemble a transaction plan from pieces of information that were not designed for the model to access.

A much better approach here is to instead expose executable functions at the right level of intent, then route to the underlying systems with explicit controls.

How an Execution Layer Helps You Narrow Down the Tool List

With intent resolution in place, instead of choosing from everything, the agent now describes what it needs in plain language, and the execution layer surfaces only the tools that fit the request, shrinking the decision before the model ever has to make it.

Engini is that execution layer, sitting between AI agents and your systems of record and connecting them to enterprise and SaaS systems through managed connectors. Rather than pushing its roughly 1,000 connectors into the agent's context window, our intent resolution surfaces only a handful of relevant tools and keeps the rest out of view, considerably cutting on token use and leaving the agent a more targeted set to pick from.

That governance lives outside the prompt as well. Engini's Agent Policy applies scoped permissions, guardrails, and an audit trail and can route high-risk actions to a person for review before they complete, while still respecting each connected system's own roles and validations.

Putting It All Together

A governed agent execution strategy starts with one decision. Begin by deciding which actions should be exposed to the model because the agent should only see functions it can use safely.

For simple single-system tasks, a native feature or focused MCP server may be enough. If the workflow stays inside one application, the tool surface can remain small, and the risk boundary is easier to inspect.

For enterprise connectivity across Salesforce, Oracle NetSuite, SAP Business One, SAP S/4HANA, or Oracle Fusion, the execution strategy needs more setup. The agent may need one path to read, another path to validate, and another path to write to the system of record.

The next critical choice is where routing should live. If routing sits inside prompts, every agent has to carry the same tool selection burden. And if routing sits inside an execution layer, the agent receives a smaller, governed set of executable functions.

So, to successfully use MCP tools within an enterprise, make sure to retain your MCP as the protocol, keep tools precise, and add intent resolution where the tool registry becomes too large for reliable model selection.

Frequently Asked Questions

What is the difference between an MCP tool and an MCP server?

An MCP server is the program that exposes capabilities to an AI client. A tool is one of those capabilities: a single executable function with a name, a description, and an input schema.

How does an AI agent find which MCP tools are available?

The client calls "tools/list" on the server and gets back each tool's name, description, and input schema. The model then reads those descriptions to decide which tool fits the request, and the client then sends the call through "tools/call" with structured arguments.

How many MCP tools should one agent see?

The MCP specification sets no fixed number. Every tool definition takes context window space, and selection gets less reliable as the list grows, so make sure to expose only the tools a task needs and group low-level endpoints into actions at the level of intent.

Are MCP tools safe to use for writes to business systems?

The protocol defines how tools are described and called and not who is allowed to call them. For writes to a CRM or ERP, you still need authentication, scoped permissions, idempotency checks, destination-system validation, and an audit trail around each call.