Model Context Protocol for Company Agents: Permissions and First Tools

The Model Context Protocol (MCP) is an open standard that lets an AI application discover and call tools offered by a separate server, using one consistent message format. For a company, exposing internal tools through MCP means each capability gets a defined name, typed inputs and a permission boundary before an agent can use it. The safest starting point is a small set of read-only tools tied to one useful role, not a catalog of everything your software can do.

Key takeaways

• MCP standardizes how an agent finds and calls tools. It does not decide who is allowed to use them, so that decision belongs in your permission layer.
• Each exposed tool needs a narrow purpose, typed inputs, a clear result and a record of which client called it.
• Start with read-only tools that answer questions your team currently looks up by hand.
• Keep payments, signatures, deletions and outbound messages behind an approval step, or leave them out of the first release.
• Judge the first tools against one observable success criterion before adding more.

What does exposing a company tool through MCP actually involve?

A company system such as a booking calendar, a customer record store or a document library already has an API or a set of internal functions. Exposing it through MCP means placing a small server between that system and the AI client. The server describes each tool it offers, including its name, a plain description and the parameters it accepts. The client reads that list and can call only the tools the server allows.

The important detail is where credentials live. The model should never receive your system password or a broad access token inside its prompt. The MCP server holds the connection to the software, applies the rules for each call and returns a result. If a request falls outside those rules, the server refuses it, and the agent receives a refusal it can report to the person it is helping.

This arrangement moves the permission question from the prompt to the server. An instruction saying the agent may only change appointments with a customer's confirmation is a request to the model. A check in the server that rejects a change without a recorded approval is a control. Build controls, and treat instructions as guidance that sits on top of them.

Why does a standard protocol change the permission question?

Without a standard, each agent gets its own custom connection to each system, and access tends to grow one integration at a time. A common protocol gives you one place to review what a connected client can reach. That reduces the number of hidden paths into your software, which is the main practical gain.

It also concentrates risk. A single server that exposes many capabilities gives any client connected to it all of them, unless you restrict each one. OWASP's authorization guidance is direct on the principle: check access on every request, deny by default, and never rely on the interface hiding a function. Apply that to each tool separately, not only to the server as a whole.

Tool output needs the same caution. A document, email or web page returned by a tool can contain text written to look like an instruction. The OWASP prompt injection guidance recommends treating model input and retrieved content as untrusted. In practice, a tool result may inform a draft, but it should never by itself authorize a payment, a deletion or a message to a customer.

Scope also changes over time. A tool built for one role may later be reused by a second agent, and that reuse should trigger a new review rather than inherit the earlier approval. Write down which role each tool was approved for, so the reason for access stays visible when the setup grows.

How do you choose the first tools to expose?

Pick the first tools from the work, not from the software menu. The sequence below keeps the choice small and testable, and it is the same logic described in what MCP is and why it matters for business agents.

• Name the one role the agent will perform, such as answering booking questions or preparing supplier follow-ups.
• Write down the questions that role must answer and the records it must look at to answer them.
• For each record, decide whether the agent only reads it, drafts something from it, or writes back to it.
• Expose read tools first, starting with records that a person currently searches for manually on a regular basis.
• Add draft tools only where a person reviews the result and sends it.
• Leave out any write action that cannot be reversed, moves money, signs a document or contacts a customer without review.
• Confirm that the source system has a stable, documented interface before building anything. If it does not, the first step is fixing that interface, not connecting an agent to it.

What permission level should each tool get?

Most business tools fall into three levels. Read tools return information and change nothing. Draft tools create a pending item, such as a reply in a review queue or a proposed calendar change, that a person accepts. Write tools change a live record or send something outward. Give each tool the lowest level that still completes the task.

The distinction matters more than the protocol itself. A read tool that returns full customer histories may expose more personal data than the role needs, so limit fields as well as actions. A draft tool is only safe if the reviewer can see exactly what will happen when they approve it. A write tool should require an approval record, and the server should store who approved the change and when. For a deeper treatment of this sequence, see least privilege for AI agents and the difference between read, draft and send permissions.

An illustrative scenario: a reschedule coordinator

The following scenario is illustrative and does not describe a real client. A small service business wants an agent to handle reschedule requests from customers. The first MCP server exposes four tools. A list_availability tool reads open slots from the calendar. A get_appointment tool reads one booking, returning only the date, address and service type. A draft_reschedule tool creates a pending change containing the proposed slot and the customer's message. A confirm_reschedule tool writes the change to the calendar, but the server accepts it only when a staff member's approval is recorded against that specific draft.

The agent answers most reschedule questions by reading availability and proposing a draft. A coordinator reviews the queue each morning and approves or corrects each item. Confirmations go out only after that approval, never on the agent's own judgment. If a customer's message asks the agent to cancel every visit and issue a refund, the agent routes the request to a person, because no tool in its list cancels or refunds. The boundary holds because it lives in the server, not in the wording of the prompt.

What should you log, and how do you know it works?

Every tool call should leave a record: which client made the call, which tool it used, the parameters with sensitive fields masked, the result status and any approval reference. Without that trail, you cannot tell whether the agent is working as intended or only appears to be. The OpenTelemetry observability concepts describe the general pattern of traces, logs and metrics, and the same discipline applies to agent tool calls.

Define success before the first tool goes live. In the scheduling example, the criterion might be that a reviewer can accept or correct each draft without reopening the customer thread. Check that criterion against a fixed set of realistic requests, and repeat the check after any change to the server, the model or the calendar software. A tool that passes today can fail after a field is renamed upstream, so recurring evaluation is part of ownership, not an optional extra.

Failures need rules too. When a call fails, the agent should report that the tool failed and stop, rather than retrying with different parameters until something works. Retry limits belong in the server, so one request cannot produce a stream of repeated calls against a live system. Review the failure log alongside the success log, because repeated refusals often show a permission that is either too narrow or quietly being tested.

How Be Human handles MCP servers in managed operations

Be Human scopes the first MCP server around one role, defines read, draft and write permissions for each tool, and keeps credentials on the server side rather than in prompts or shared notes. Managed operations then cover the parts that change after launch: monitoring of tool calls, recurring evaluations against the agreed criterion, maintenance when upstream interfaces change, periodic permission review and incident response when a boundary is tested. The goal is that the limits agreed at the start are still the limits in place after the next change, and that each new tool is added only after the first one has been checked.

If you are not sure which of your tools deserves to be the first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Is MCP the same as giving an AI agent full access to my software? No. MCP is a way for a client to connect to tools that a server chooses to expose. The access an agent gets depends on which tools you build, what each one can do and how the server checks every call. A well-designed server exposes a few narrow capabilities rather than the whole system.

Do I need MCP to connect an agent to my business tools? Not always. Some integrations use a direct API or a platform's built-in connector, and those can be sound choices for a single system. MCP becomes more useful when several tools must be offered consistently to one or more agents, and when you want one place to review what each client can reach.

Which tool should I expose first? Choose a read-only tool that answers a question your team already answers by looking up the same record. Keep it narrow, return only the fields the role needs and log every call. Add draft or write tools only after the read tools pass the check you agreed on in advance.

Who should approve changes to an MCP server? The person who owns the business process should approve what the agent may do, and the person responsible for the systems should approve how the server reaches them. Keep a written record of both decisions. Review permissions again whenever a tool is added, a field changes or an approval step is bypassed.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.