MCP Tools: How They Work, Use Cases & Best Practices

What Are MCP Tools? 

Model Context Protocol (MCP) Tools are executable functions exposed by MCP servers that allow AI models (like Claude Desktop and Cursor) to securely interact with external systems, databases, and APIs.

Unlike resources, which usually provide readable context, tools let the model perform an operation, such as querying a database, calling an API, running a calculation, creating a ticket, retrieving live data, or triggering a workflow.

Each tool is described with structured metadata, including a unique name, a human-readable description, and an input schema that defines what parameters the tool accepts. Clients can discover available tools, understand what each tool does, and invoke the right one by sending a structured tool call. The server then executes the requested operation and returns a result, which may include text, structured data, images, audio, links to resources, or embedded content.

Why MCP Tools Matter 

Enable AI Models to Take Real Actions

MCP tools turn AI systems from passive text generators into systems that can perform work. Instead of only explaining how to complete a task, an AI model can use a tool to fetch current information, update a record, search an internal system, analyze a file, open a support ticket, or run a workflow. This makes agents more useful in business and technical environments where answers require live data or external execution.

This capability is important for agentic workflows. A model can reason about the user’s goal, determine that an external action is needed, select the appropriate tool, provide the required arguments, and use the result to continue the task. For example, an agent could check inventory, summarize the result, and then create a follow-up task if stock is low.

Make External Capabilities Visible Through Structured Schemas

MCP tools make external capabilities discoverable in a structured, machine-readable way. A tool definition tells the client and model what the tool is called, what it does, and what input it expects. This reduces ambiguity because the model does not need to guess how to call an API or format a request manually.

Structured schemas also make tools easier to validate, document, test, and maintain. When each tool has a defined input schema and, optionally, an output schema, developers can create clearer contracts between the AI application and the underlying system. This helps models call tools more accurately and helps engineering teams expose capabilities without relying on brittle custom prompt instructions.

Support Safer Execution

MCP tools support safer execution by creating a clear boundary between the model’s reasoning and the operation performed by the server. The model requests a tool call, but the server controls how that request is validated, authorized, executed, logged, and returned. This allows developers to add safeguards such as schema validation, access checks, rate limits, timeouts, audit logs, and error handling.

Tool use also depends on user visibility and approval. For sensitive actions, applications should clearly show which tool is being invoked and allow a human to approve or deny the operation. This is important because tools can modify data, interact with production systems, call external services, or trigger workflows with real-world consequences.

Allow Enterprises to Expose Approved Capabilities to AI Agents

MCP tools give enterprises a standardized way to expose approved internal capabilities to AI agents. Instead of allowing agents to directly access databases, APIs, file systems, or SaaS platforms in an uncontrolled way, organizations can wrap approved actions as MCP tools with clear schemas, permissions, and execution policies.

This helps enterprises build controlled AI workflows across systems such as CRM, ITSM, security platforms, data warehouses, developer tools, and internal knowledge systems. Teams can decide which tools are available, who can use them, what inputs are allowed, what actions require approval, and how tool usage is monitored. As a result, MCP tools become a foundation for governed AI adoption rather than ad hoc integrations.

How MCP Tools Work 

1. The Server Declares Tool Support

An MCP server begins by declaring tool support as part of its capabilities. This tells the MCP client that the server can expose executable functions that may be invoked during a model-driven workflow. Without this capability declaration, the client should not assume that tools are available from that server.

Once tool support is enabled, the server defines the tools it can provide. Each tool has a unique name, a description, and an input schema that explains what arguments the tool accepts. These definitions act as a contract between the server, the client, and the model. For example, a server might expose tools for searching documents, querying a database, creating a ticket, sending a notification, or performing a calculation.

The server is responsible for handling tool execution securely. It must validate inputs, enforce permissions, interact with the underlying system, manage errors, and return results in a format the client can pass back to the model.

3. The Client Lists Available Tools

After the client connects to the server, it can request the list of available tools. The server responds with the tool definitions it currently exposes, including names, descriptions, and schemas. This discovery process allows the AI application to understand what actions are available without hardcoded integrations for every external system.

Tool listing is important because available capabilities may vary by server, user, environment, policy, or runtime state. A development server might expose code and file tools, while an enterprise server might expose approved tools for CRM updates, IT ticketing, security investigation, or internal search. In some cases, servers can also notify clients when the tool list changes, allowing the client to refresh its view of available capabilities.

The quality of tool descriptions matters at this stage. Clear names and detailed descriptions help the model understand when a tool should be used, what the tool does, and what kind of input it requires.

3. The Model Selects a Tool

Once the client has the available tool definitions, the model can decide whether a tool is needed to satisfy the user’s request. The model evaluates the user’s intent, the context of the conversation, and the available tools. If a tool is relevant, the model selects the appropriate one and prepares the required arguments according to the tool’s schema.

For example, if the user asks for live account status, the model may select a customer lookup tool. If the user asks to summarize a file, it may select a file-reading or document-analysis tool. If the user asks to create an issue, the model may choose a ticketing or project-management tool.

This selection is model-driven, but it should not be uncontrolled. The host application can apply policies, require user approval, restrict certain tools, or block actions that are too risky. In well-designed implementations, the model chooses from approved capabilities rather than having unrestricted access to external systems.

4. The Client Calls the Tool

After the model selects a tool, the client sends a structured tool call to the MCP server. The request includes the tool name and the arguments the model generated. These arguments should match the tool’s input schema, allowing the server to process the request predictably.

Before execution, the client or host may show the user what action is about to happen. This is especially important for tools that write data, send messages, modify records, run commands, access sensitive information, or affect production systems. Depending on the risk level, the host may require explicit approval before the tool call proceeds.

The server then validates the request. It checks whether the tool exists, whether the arguments are valid, whether the caller is allowed to use the tool, and whether the operation is safe to perform. This validation step is critical because model-generated inputs can be incomplete, incorrect, or influenced by untrusted context.

5. The Server Returns Results

After executing the tool, the server returns a structured result to the client. The result can contain plain text, structured data, images, audio, embedded resources, or other content types supported by the protocol. The client then provides this result back to the model so it can continue reasoning and produce a response for the user.

Tool results may represent a successful action, such as “ticket created,” “query completed,” or “file analyzed.” They may also include error information if something went wrong, such as invalid input, missing permissions, unavailable systems, or failed execution. Tool errors should be returned in a way the model can understand and respond to, rather than as vague technical failures.

In many workflows, the first tool result is not the end of the process. The model may use the returned data to answer the user, ask a follow-up question, invoke another tool, or combine several tool outputs into a final response. This is what makes MCP tools useful for agentic workflows: they let AI systems move through a loop of reasoning, action, observation, and response while relying on structured server-side execution.

MCP Tools vs. MCP Resources vs. MCP Prompts 

MCP tools, resources, and prompts are three different MCP primitives, each serving a different role in how AI applications interact with external systems. Tools are used for action, resources are used for context, and prompts are used for reusable instructions or workflows:

• MCP tools expose executable functions that an AI model can call through a client. They are used when the model needs to perform an action, such as query an API, create a ticket, analyze a file, run a calculation, update a system, or trigger a workflow. Tools are typically dynamic because their results depend on input arguments and may involve external systems, live data, or state-changing operations.
• MCP resources expose information that the model can read or reference. They are suited for context such as documents, files, database records, logs, configuration data, code, or application state. Unlike tools, resources are generally read-oriented. They help the model understand the user’s environment or retrieve relevant background information without performing an action.
• MCP prompts provide reusable prompt templates or guided interaction patterns. They are used to standardize how users or applications start common tasks, such as summarizing a report, generating a code review, drafting a support response, or running an investigation workflow. Prompts shape the model’s behavior, but they do not execute external actions or expose raw data by themselves.

The simplest way to understand the difference is: tools let the model act, resources let the model read, and prompts guide how the model should work. In an MCP workflow, all three can be used together. For example, a prompt might guide an incident investigation, resources might provide logs and system context, and tools might query monitoring systems or create a remediation ticket.

Related content: Read our guide to agentic AI tools.

Tutorial: MCP Tools Example 

The following example shows how an MCP server exposes a simple tool that adds two numbers together. Although the operation is basic, it demonstrates the complete tool lifecycle: defining the tool, exposing it to clients, receiving a tool call, executing the requested operation, and returning the result.

Step 1: Define the Tool

The server exposes a tool named multiply_numbers. The tool definition includes three parts:

• A unique name (multiply_numbers)
• A human-readable description (Multiply two numbers together)
• An inputSchema that describes the expected parameters

The input schema uses JSON Schema to specify that the tool accepts two required numeric inputs named a and b.

app = Server("example-server")


@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="multiply_numbers",
            description="Multiply two numbers together",
            inputSchema={
                "type": "object",
                "properties": {
                    "a": {"type": "number"},
                    "b": {"type": "number"}
                },
                "required": ["a", "b"]
            }
        )
    ]

When a client requests the available tools, this definition is returned through the tools/list endpoint so the client and model can discover that the capability exists.

Step 2: Implement Tool Execution

The server also implements a handler that executes the tool when the client invokes it through the tools/call endpoint.

@app.call_tool()
async def call_tool(
    name: str,
    arguments: dict
) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]:
    if name == "multiply_numbers":
        a = arguments["a"]
        b = arguments["b"]
        result = a + b
        return [types.TextContent(type="text", text=str(result))]
    raise ValueError(f"Tool not found: {name}")

The handler checks which tool was requested, reads the input arguments, performs the calculation, and returns the result as text. If the requested tool does not exist, the server returns an error.

Step 3: Understand the Flow

In this example, the workflow is straightforward:

1. The client requests the available tools from the server.
2. The server returns the multiply_numbers definition.
3. The model decides to use the tool and provides values for a and b.
4. The client sends a tools/call request with those arguments.
5. The server multiplies the two numbers and returns the result.
6. The client passes the result back to the model so it can continue responding to the user.

Although this example performs a simple calculation, the same pattern applies to more advanced tools. An MCP server can expose tools that execute system commands, create GitHub issues through an API, or analyze CSV files by accepting structured inputs and returning the requested results.

Best Practices for Designing and Securing MCP Tools 

Here are some of the ways that organizations can improve their use of MCP tools.

1. Keep Tool Scope Narrow

Each MCP tool should perform one clear, specific function. Narrowly scoped tools are easier for models to understand, easier for developers to test, and easier for security teams to review. For example, a tool named get_customer_invoice_status is safer and more predictable than a broad tool named manage_customer_account.

Avoid creating tools that can perform many unrelated actions based on a generic command parameter. Overly broad tools increase the risk of misuse because the model may call them incorrectly or combine inputs in unexpected ways. A narrow tool design also makes it easier to apply targeted permissions, logging, rate limits, and approval requirements.

Key actions:

• Design each tool to perform one specific task.
• Avoid generic tools with multiple unrelated functions.
• Use clear, descriptive tool names and descriptions.
• Separate read and write operations into different tools.
• Review tools regularly to remove unnecessary capabilities.

2. Define Strict Input Schemas

Every MCP tool should have a clear input schema that defines exactly what arguments are allowed, which fields are required, and what data types are expected. This reduces ambiguity and helps prevent malformed or unsafe tool calls. Schemas should be specific enough to guide the model and restrictive enough to reject unexpected inputs.

Use constraints such as enums, minimum and maximum values, string length limits, required fields, and structured object definitions where appropriate. Do not rely on natural-language descriptions alone to enforce safe behavior. The server should validate all inputs before execution, even when the request appears to come from a trusted client or a well-behaved model.

Key actions:

• Define required fields and supported data types.
• Use enums, ranges, and length limits where appropriate.
• Validate all inputs before execution.
• Reject unexpected or malformed arguments.
• Keep schemas synchronized with tool implementations.

3. Implement Access Controls

MCP tools should enforce access controls based on the user, application, environment, and action being requested. The model should not receive broad permissions simply because it can see a tool. A user should only be able to invoke tools that match their role, business need, and authorization level.

Access control should be enforced on the server side, not only in the prompt or client interface. For example, a support agent might be allowed to view customer status but not issue refunds, while an administrator may have broader permissions. In enterprise environments, MCP tools should integrate with existing identity providers, role-based access control, policy engines, and audit systems when possible.

Key actions:

• Enforce permissions on the server for every tool call.
• Apply role-based or attribute-based access controls.
• Restrict tools based on user, application, or environment.
• Integrate with enterprise identity providers where possible.
• Log all authorization decisions for auditing.

4. Rate Limit Tool Invocations

Rate limiting helps prevent accidental overload, abuse, runaway agent loops, and excessive use of external systems. MCP tools should have clear limits on how often they can be called, how many records they can return, and how many operations they can perform in a given time window.

Limits can be applied per user, per session, per tool, per tenant, or per connected system. This is especially important for tools that call paid APIs, query production databases, send messages, run scans, or trigger automation. Rate limits should be paired with clear error responses so the model can recover gracefully instead of repeatedly retrying the same failed action.

Key actions:

• Set rate limits for users, sessions, and applications.
• Limit expensive or high-impact operations.
• Prevent recursive or runaway agent loops.
• Return clear errors when limits are exceeded.
• Monitor usage patterns and adjust limits over time.

5. Require Confirmation for Sensitive Actions

Sensitive MCP tools should require explicit human confirmation before execution. This includes tools that send emails, delete files, update production systems, change permissions, create financial transactions, expose confidential data, or trigger irreversible workflows. Confirmation gives the user a chance to review what the model is about to do before the action happens.

The confirmation step should show the tool name, the intended action, the target system, and the key input values in plain language. This helps users catch mistakes, prompt-injection attempts, or unintended consequences. For lower-risk tools, confirmation may not be necessary, but for high-impact actions it should be treated as a standard safety control rather than an optional feature.

Key actions:

• Require approval before executing high-risk operations.
• Display the tool name, action, and key inputs for review.
• Require confirmation for destructive or irreversible changes.
• Allow users to cancel or modify pending actions.
• Record confirmations in audit logs for accountability.

Monitoring MCP and OpenAI Agent Activity with Exabeam

As organizations connect OpenAI models to MCP servers, AI agents become a new class of non-human identity operating inside business systems at machine speed and scale. Exabeam delivers advanced user and entity behavior analytics (UEBA) that uses AI and automation to help security operations teams detect, investigate, and respond to threats involving users, entities, and AI agents through Agent Behavior Analytics (ABA). By baselining what normal behavior looks like and surfacing risky deviations, Exabeam gives teams the visibility needed to govern MCP-enabled OpenAI agents and the workflows they touch.

Key capabilities of Exabeam UEBA:

• AI agent behavior analytics: ABA extends UEBA to AI agents and other non-human identities, adding behavioral visibility, centralized monitoring, and investigation support so analysts can identify suspicious agent activity and respond with better context.
• Risk-based anomaly detection: New-Scale Analytics builds behavioral baselines and uses business context to refine risk scores, identifying subtle changes across users, entities, and non-human identities; when risk meets a set threshold, a case is opened for investigation.
• Entity context: Attack Surface Insights identifies entities in parsed logs and connects attributes and contextual data to build profiles that strengthen behavioral detections across on-premises and cloud environments.
• Automated investigation timelines: Automated timelines organize related detections chronologically to visualize the full scope of a threat, while activity summaries for anomalies and prebuilt playbooks reduce manual routines so teams respond faster.
• Flexible SIEM augmentation or replacement: New-Scale Analytics runs on top of an existing SIEM to add advanced behavioral analytics, while New-Scale Fusion provides a full-featured platform for a new deployment or a SIEM replacement.

Integrating ABA with Praxen and Observra

To secure AI agents, Exabeam combines runtime analytics with open-source frameworks for telemetry and verification. Integrating Agent Behavior Analytics (ABA) with Praxen and Observra creates a comprehensive security lifecycle for autonomous machine identities.

• Standardizing Agent Telemetry with Observra: Active AI agents generate complex, unstructured activity logs. Observra acts as an open-source SDK and logging library that captures runtime agent operations, including model calls, prompt details, tool usage, system costs, and errors. It normalizes this data into a structured event format, providing the consistent telemetry stream required for advanced threat detection.
• Verifying Agent Policies with Praxen: Before an agent is deployed, Praxen serves as an open-source reference implementation for Agent Behavior Verification (ABV). It compares the declared security policy of an AI agent against its actual underlying code, deployment state, and initial behavioral logs. This ensures that discrepancies, logic flaws, or unauthorized capabilities are flagged before the agent enters production.
• Continuous Behavioral Analysis with ABA: During active operations, the ABA engine ingests normalized telemetry from Observra and leverages the policy baselines established by Praxen. The engine applies machine learning models to build behavioral baselines for each agent, scoring risks and flagging real-time anomalies. If an agent drifts from its intended role, calls unapproved tools, or accesses unauthorized data, ABA immediately raises risk scores and triggers alerts.

This combined approach allows security teams to verify AI agent behavior prior to deployment and maintain continuous, baseline-driven visibility throughout active operations.

Exabeam offers a Model Context Protocol (MCP) server for developers that connects AI assistants directly to public API documentation, enabling teams to explore endpoints, analyze request and response schemas, and generate custom integration code through natural language conversation. In parallel, LogRhythm delivers a community-released SIEM MCP server that runs locally in on-premises environments to bridge security telemetry directly with chosen large language models, allowing analysts to run automated threat-hunting queries, triage active incidents, and summarize security alarms while keeping sensitive security logs inside the private.

To see how Exabeam helps security teams monitor and secure human and AI agent activity across the agentic enterprise, explore Exabeam’s UEBA capabilities. Read our MCP for Developers page to learn more on MCP as well.