MCP for Business: Which Internal Systems to Expose as Tools

An MCP server for business is a bounded set of tools that lets an AI agent read from or act on one of your internal systems through the Model Context Protocol, an open standard for connecting models to tools and data. The useful decision is not whether a system can be connected, but which of its actions an agent should perform without a person in the loop. Expose read access and narrow, reversible actions first, and keep payments, legal commitments, deletions and anything a customer sees behind an interface that a person operates.

Key takeaways

• Expose a system through a tool server only when a specific, repeated task needs it, not because a connection happens to be available.
• Start with read-only tools that return bounded, labeled results, then add narrow write actions one at a time.
• Keep money movement, legal commitments, deletions, bulk changes and customer-facing messages behind a human-run interface.
• Give every tool a named owner, a permission scope, a call log and a way to revoke access without rebuilding the agent.
• Judge each exposure by one observable success criterion, reviewed on a schedule.

What MCP standardizes, and what it leaves to you

The Model Context Protocol gives a client a consistent way to discover the tools a server offers, read their descriptions and input shapes, and call them. That consistency matters. A tool built once for your order system can be reached by different agent clients without a custom connector for each one. The protocol does not decide what the tool is allowed to do. Those decisions live in the server, in the credentials it holds and in the system behind it.

Treat every tool as an authorization boundary. The OWASP authorization guidance makes the principle plain: access checks belong in server-side logic that runs on each request, not in instructions given to a model. A tool that accepts any customer identifier and returns that customer's records is not protected by a sentence in the prompt telling the agent to look up only the current customer. The check has to exist in the tool itself.

Tool descriptions and returned content are also text that the model reads. Documents, emails and web pages can contain instructions aimed at the agent, which is the prompt injection problem described in OWASP's cheat sheet on the subject. An exposed tool should assume its inputs may be hostile, validate them against a strict shape, and never let a returned string grant new permissions or widen a request.

A decision guide for each internal system

Work through the same questions for every system on your list. A system that fails the first two can wait, whatever its API looks like.

• Is there a repeated task that needs this system's data or actions, with a named person who will use the result? If not, do not expose it.
• Can the system scope access to one account, project, region or object type? If not, the server must add that scope itself, or the system stays out.
• Can each action be reversed within a known window, or is it final? Final actions stay behind a human interface.
• Does the action touch money, a signed or legal position, a patient or customer record, or a message that leaves the company? Those require a human decision.
• Does the system accept an idempotency key or offer a duplicate check? Without one, a retry after a timeout can repeat a write.
• Can you log each call with the identity used, the inputs, the result and the time? If not, the tool is not ready.
• Who revokes access, and how fast? Name the person and the procedure before launch.

Most companies find that the first pass removes more systems than they expected. A contact list can often be exposed for lookups. A bank account should rarely be exposed for anything beyond balance reads, and even those deserve a separate review before they are connected.

Start with read-only tools that return bounded results

Read access is the lowest-risk place to begin, and it is also the most revealing. A read tool shows you where the data is messy, which fields are missing, and which questions people actually ask. Those findings shape any write action you add later. For the mechanics of database-level read access, see how to connect an AI agent to a database with read-only access.

A good read tool is bounded in four ways. It returns a fixed maximum number of rows, uses cursors for further pages, and includes only the fields the task requires. Every answer carries the time the data was last synced, so a stale figure is never presented as current. When nothing matches, the tool says so explicitly instead of returning a close guess.

A read tool that says no match was found is more useful than one that returns the nearest record.

Illustrative scenario: a distributor exposes one read tool that returns the status of open purchase orders for a single supplier, with a fixed row limit and the last sync time in every response. Sales staff can ask about delivery status without opening the ERP, and no one can change an order through that tool. If the supplier record is missing a delivery date, the answer says the date is not in the system rather than estimating one.

Which write actions are safe to hand over

Write actions should start narrow and reversible. Creating a draft, attaching a file to a record, adding an internal note or proposing a reschedule within published rules are good first candidates. Changing a committed record, sending a message, or closing a case is a later decision, taken only after the read and draft behavior has been reviewed in real use.

Duplicates are the most common write failure. An agent that retries after a timeout can create a second order, a second booking or a second invoice if the action is not idempotent. Some providers build this in. Stripe, for example, documents idempotency keys that let a client repeat a request safely without repeating its effect. Where the target system offers no such mechanism, the tool server needs its own record of completed actions and must check it before writing. The pattern is covered in more depth in idempotent AI agent actions.

Keep the write tool's inputs as strict as its reads. Accept only the fields the action needs, reject values outside allowed ranges, and return a clear result object that states what changed. A vague success message makes incident review harder than it needs to be.

What should stay behind a human-run interface

A human-run interface is the system's own screen or an approval queue where a person makes the final commit. The agent prepares the work, gathers the facts, drafts the document or fills the form. The person reviews and clicks. This is not a failure of automation. For some actions it is the correct design, because the consequence of an error is larger than the time saved by removing the click.

The following categories should stay behind that boundary unless a specific, reviewed case justifies otherwise:

• Payments, refunds, credit notes and any change to bank or payout details.
• Signatures and any commitment that binds the company to a third party.
• Deletions, bulk edits, and changes to permissions, roles or pricing.
• Customer-facing or patient-facing messages that no person has reviewed.
• Decisions about eligibility, credit, clinical content or legal exposure.

The boundary is not permanent. Movement across it should follow evidence: a period of logged, reviewed use, a clear success criterion, and a named person who accepts the change. For payments in particular, the limits deserve their own written rules, as discussed in safe payment limits for AI agents.

A checklist before launch, and how it runs afterward

Before any tool server goes live, confirm each item in writing:

• A one-page tool matrix lists each tool, its owner, its scope, its permitted actions and its approval rule. A template for this is described in the least-privilege tool matrix.
• Each tool uses its own credential with the smallest scope that works, and no tool shares a broad account with another.
• Every call is logged with identity, inputs, result and time, and someone reviews those logs on a set schedule.
• Write tools have a duplicate check or idempotency key, and retries have been tested.
• A revocation procedure exists, has a named person, and has been rehearsed once.
• One observable success criterion is defined for each tool, and the review date is on the calendar.

Be Human designs and operates this kind of layer for companies. The exposure decisions above are written down as a tool matrix with owners, scopes and approval boundaries before anything is connected, so each permission has a reason a person can read. Managed operations then keep those decisions current: monitoring of tool calls, permission reviews when a team changes, incident response when a vendor API shifts, and controlled improvements when a tool is widened. The first engagement defines one useful role, the memory and tools it needs, its approval boundaries and one success criterion, which keeps the first exposure small enough to measure. If you are unsure which of your systems should be exposed first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Is an MCP server the same as giving an AI agent full access to a system? No. An MCP server exposes only the tools you define, and each tool can be limited to specific actions, objects and data. Access should be designed as a set of narrow tools with their own credentials, not as one connection to everything the system can do.

Should we wait for the protocol to mature before exposing anything? Not necessarily. The protocol handles how tools are described and called, while the work that carries real risk, which is scoping, logging, duplicate prevention and approval, is the same whichever standard carries it. A small read-only tool can be built and reviewed now, and it can be moved later if your client tooling changes.

How do we know a tool is working well enough to widen its permissions? Define one observable success criterion before launch, such as the share of lookups a person accepts without correction, and review it on a schedule. Widen a tool only when that criterion holds over a period of real use and the call logs show no unexpected patterns. If the logs show surprises, fix the cause before any change in scope.

Who should own a tool server inside the company? Assign a business owner who decides what the tool may do, and a technical owner who maintains credentials, logs and vendor changes. The business owner signs off on scope changes, while the technical owner can revoke access immediately if an incident occurs.

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