MCP and AI agents: A guide for business operators

MCP, short for Model Context Protocol, gives AI agents a common way to connect to external tools and services. For a business operator, that means an agent can potentially work with information and actions in systems such as email, customer relationship management software and team knowledge bases, rather than relying on copied text or a person moving data between apps. The important change is access. Once an agent can reach a business system, someone must decide what it can read, what it can change and which actions require approval.

You do not need to understand the protocol's implementation to make those decisions. You do need to understand what a connection permits. MCP can give an agent a route to a tool, but it does not decide whether the agent should use that tool for a particular task. That remains a question of permissions, the brief, the cost of a mistake and the point at which a person must take over.

What MCP changes for an AI agent

An AI agent needs more than a language model to do useful work outside a conversation. It needs access to relevant information and a way to take permitted actions. Without a connection, an agent might draft a customer reply from text supplied in a brief. With suitable tool access, it might retrieve the relevant conversation, check a customer record and prepare a reply based on both.

MCP provides a shared protocol for connecting AI applications to external capabilities. An MCP server can expose tools or resources that a compatible client can discover and use. A tool might search for a document, retrieve information or request an update to a record. The available capabilities depend on the server and its configuration.

This common approach can reduce the need to build a separate, bespoke connection for every AI application and service combination. It does not mean every service becomes available automatically, or that every agent can use every MCP server. Compatibility, authentication, configuration and permission still matter.

For operators, the practical difference is that the agent's working environment can extend across several business systems. A research task might involve reading internal notes and checking a CRM record. A support task might involve finding a customer's history and drafting a response. The same access that saves manual work can also expose information or allow a change the task never required.

A connection is not a permission policy

Suppose you want an agent to prepare a list of overdue customer accounts. It needs to read relevant records and calculate which accounts need attention. It probably does not need permission to edit payment terms, issue refunds or send collection emails. Giving it a broad connection because the task might need one small part of it creates unnecessary risk.

This is where scope matters. A scope defines the access an integration grants, such as permission to read certain data or perform particular actions. The exact scope depends on the service and the authentication method. An operator should ask for the smallest set of permissions that allows the agent to complete its assigned work.

Read access and write access should be treated differently. Reading a customer note can expose sensitive information, so it still needs a business reason. Editing that customer's account introduces another risk because the agent may change a record that other employees rely on. Sending an email adds an external consequence that cannot be fully undone.

Before connecting an MCP server or another integration, ask the person responsible for the system to confirm what the connection can access, whether it can make changes and how access can be revoked. If a task needs broader permissions later, review the new requirement at that point. Do not grant extra access in anticipation of work that may never happen.

Decide which actions need a person

A technical permission tells you what an agent can attempt. An approval rule tells you what it is allowed to do without a person checking first. Those are different controls. An integration may technically permit an agent to send email, but your operating policy can still require a person to approve every outbound message.

The right boundary depends on the consequence of an action, not simply on which tool performs it. Searching an inbox and sending a message may use the same integration, yet they carry different levels of risk. Preparing a draft can be delegated. Sending it to a customer may need a separate decision.

For an operator, it helps to write down the boundaries before the first delegation. A practical policy might allow an agent to read approved folders, prepare CRM updates and draft customer replies. It might require approval before sending a message, changing an existing record or publishing content. Money movement, account access changes and actions in another workspace deserve particularly firm limits.

In Delagents, the approvals inbox holds actions that affect anything outside the workspace. Each card shows the exact proposed action, the cost so far and a deadline. A person can approve it, change it or reject it. Connecting an integration or widening its scopes also requires a person, so an agent cannot expand its own access as a shortcut to finishing a task.

An approval is useful only when the reviewer has enough information to make a decision. A card that says "Update CRM" leaves too much unsaid. The reviewer needs to know which record will change, what the proposed change is and why the task calls for it. If the action cannot be explained clearly, it is not ready for approval.

Trace the work across connected systems

When an agent uses several tools, a completed task can leave changes in more than one place. A support agent might read an email, consult a knowledge base, prepare a response and propose a CRM update. If the final record is wrong, the operator needs to establish which information the agent used and what happened at each step.

That is why the audit trail should record tool calls as well as final deliverables. A useful record includes which delegation was running, which tools were called, which approvals were requested and what a person decided. Policy changes matter too. If an integration's permissions changed between two runs, a reviewer should be able to see that fact rather than infer it from the result.

An append-only activity log gives the team a history that cannot be silently rewritten through ordinary editing. It does not prove that every result is correct, and it cannot replace careful access control. It does give an operator evidence to inspect when something goes wrong or when a task needs to be reviewed later.

Set a budget for the work as well. Tool calls, retries and extended runs can consume resources without producing a useful deliverable. A hard cap on each delegation puts a limit on that exposure. The agent should stop when it reaches the cap rather than quietly continuing to spend.

These controls answer different questions. Scopes limit what the agent can access. Approval rules limit which consequential actions it can take without a person. Logs record what happened. Budgets limit the cost of a run. None replaces the others.

Choose the first MCP-enabled workflow carefully

The first workflow should be narrow enough that you can check the result without building a new review process around it. Start with a task that has a clear input, a defined output and a low cost of failure. Research preparation, inbox classification and draft creation are reasonable candidates because a person can inspect the work before anything consequential happens.

Map the workflow before connecting tools. Write down the information the agent needs, the systems it must reach, the actions it should prepare and the actions it must never complete alone. Then check whether each requested permission serves one of those steps. If an agent only needs to read a record and draft a response, a request for broad write access deserves a second look.

• Write a brief with a specific deliverable and a clear definition of done.
• List the systems and individual capabilities the task needs, separating read access from write access.
• Set approval points for external messages, record changes and any other action with a material consequence.
• Set a hard spending limit and decide what the agent should do when it cannot finish within that limit.
• Review the deliverable, activity log and approval history before expanding the task.

If the workflow depends on business applications, start by checking the integrations already available to your team. Delagents lists connections such as Gmail, Slack, HubSpot and Notion on its integrations page. Treat each connection as a specific grant of access, not as permission for an agent to do anything that looks useful.

For your first test, choose one task that currently involves copying information between two systems. Give the agent read-only access where possible, ask it to produce a deliverable and keep any external change behind a human approval. Review the result and the recorded tool calls. Only widen the scope after you can explain exactly what the extra permission will allow and why the task needs it.