MCP for Business Owners: A Shared Language, with Permission at Every Door

The owner sees an assistant answer a stock question in a demo. By Monday, she wants it connected to orders, inventory and accounting. Her operations lead has a different question: when a branch manager asks, which branch’s records will the assistant actually be allowed to see?

This is a fictional retailer, but it is the right purchasing conversation. A common connection format can reduce integration work. It cannot decide the company’s permissions, make every answer correct or keep data local by itself. MCP—the Model Context Protocol—provides that common language, while people still choose the boundaries.

This is part 2 of our operations-AI series. Part 1 chooses appropriate agent work; part 3 covers approvals and audit evidence. No code is needed to follow the connection below.

One shared language, three different jobs

MCP describes how an AI application discovers and uses capabilities offered by another program. Think of a familiar plug shape: useful for compatibility, but the shape alone does not tell you who may use a device or what it is allowed to expose.

The host is the assistant application people use. Its client component talks to an MCP server. That server translates permitted requests into the business system’s existing operations. It is a software role, not necessarily another physical machine. A host can connect to several servers.

A server can offer resources (context identified by a URI), tools (callable functions) and prompts (reusable message templates). A stock lookup can be a read-only tool; “tool” does not mean “write”, and “resource” does not mean “non-sensitive”. A prompt template is not an access policy. Ask which features the actual host and server support, rather than assuming they expose all three.

Reusable parts are not fewer permission paths

Imagine three assistant applications and three business systems. A naive bespoke design might maintain nine pair-specific integrations. MCP can replace repeated protocol work with reusable host/client support and server interfaces—conceptually three plus three components.

If every assistant uses every system, there are still three × three = nine logical access paths to configure and authorise. “Six reusable components” does not mean “six live connections”. Implementations may share infrastructure or combine systems, and adapter effort is not always equal. This is a design illustration, not a guaranteed saving.

Business mapping, units, identifiers, validation and downstream APIs still need work. Keep the authoritative business rules in the system that owns the operation, and reuse them across screens, APIs and MCP. Hosts and model providers also have their own security responsibilities; MCP does not move every rule into a single magical gateway.

Follow one stock question, without exposing the whole company

In our teaching example, a manager may read Store 2 stock but not other stores’ margins or payroll. She asks how many bottles can currently be sold from her location. The host uses a permitted stock lookup; the server checks identity, scope, store and field access before returning data.

At the stated snapshot time, physical on-hand is 50, including 5 on quality hold. Of the 45 approved units, 20 are already reserved. Current free approved stock is therefore 50 − 5 − 20 = 25. These categories are explicitly non-overlapping in this example. Do not subtract reservations or holds twice if a system’s “available” figure already excludes them.

The answer includes the location, units, status basis and evidence time. It does not include customer addresses or supplier cost just because the database has them. Twenty-five free units are a snapshot, not a delivery promise or a future-demand forecast; the next order can change availability.

If the manager asks for another store’s restricted figures, access is denied before retrieval. Filtering only the final sentence is too late if the restricted records already went into model context, a cache or a log. A later draft purchase order is a separate permission and workflow; answering the stock question grants no right to buy.

Identity, consent and business rights are separate checks

For protected remote HTTP connections, review the MCP authorisation specification with your supplier. It describes an OAuth-based framework. Authorisation is optional at protocol level; that is not permission to expose private ERP data anonymously. For local stdio processes, the HTTP OAuth flow is not the prescribed pattern: credentials and operating-system access need separate control.

Signing in identifies a user; consent authorises a client’s access; scopes limit a token; application rules decide whether this user may read this record or approve this action. OAuth does not automatically reproduce every ERP role, record filter or approval rule. Effective access must respect user rights, delegated tool scope and current policy on every call.

Ask how token audience/resource validation, PKCE where applicable, secure storage, expiry, revocation and user-disable checks work. None is a universal shield against stolen credentials or a compromised host. Never pass one service’s token through to an unrelated service as a shortcut. Unattended work needs a limited service identity, owner and review; it must not silently impersonate a manager.

A local MCP server is executable software. Choose a trusted publisher and controlled version, and understand which files, credentials and network destinations it can access. “Runs on my laptop” is not a security certificate.

Map the data journey before connecting

The server may run beside your ERP while the host or model runs elsewhere. The host determines which returned context reaches a model or other service; not every returned byte must automatically be forwarded. Inspect the actual journey, including prompts, results, caches, logs, support access, subprocessors, retention and training terms.

Use the smallest necessary fields, permitted records and an approved model destination. Customer text, internal notes and supplier files may contain hostile instructions; being inside the company does not make a document trusted authority. Tool descriptions and read-only hints are also not proof of safe implementation. Application checks must remain effective even if the model asks for something wrong.

Ask the vendor to demonstrate the boundaries in the table. Audit evidence helps investigate an event; it does not prevent one merely by existing. Protect and redact it rather than storing every raw argument and result indefinitely.

Boundary	Practical proof to request
Identity and records	A manager cannot fetch another store’s restricted record, even by its ID
Data minimisation	Stock response omits private cost, addresses and unrelated fields
Action control	Draft creates no hidden reservation/send; execution requires the proper approval
Failure recovery	Unknown committed result is reconciled; retries cannot duplicate it
Evidence and revocation	Restricted, redacted audit record; access stops under the stated disable/revocation policy

Ask about versions without buying a scaling promise

This review checked the official 2026-07-28 specification, whose core uses self-contained requests. Earlier revisions used connection-scoped sessions. Ask which revision, transport and optional features both ends actually implement, how compatibility is tested and who owns updates.

Protocol statelessness does not make a purchase workflow stateless or eliminate shared business data. Authentication, capacity, database consistency, operation references and long-running work still need design. A protocol version alone is not evidence that adding load balancers will safely scale an ERP.

A first connection small enough to inspect

Choose one manager, one location and one useful lookup. Record the allowed fields, evidence freshness, provider destination and owner. Compare answers with the source system, including empty, stale and ambiguous cases. Test a direct request for a forbidden record—not only whether its menu is hidden.

Then test an instruction embedded in a document, expired/revoked access, a changed tool definition and a provider outage. Before any write tool is introduced, test exact-version approval, a genuinely inert draft and a timeout after commit. Reconcile the existing operation before bounded backoff/retry; prevent duplicate commitments and give uncertain outcomes an owner. Do not keep retrying denied or invalid requests.

Expand only when the tests and business value justify it, not because four weeks have elapsed. The StoreConsole demo shows business workflows to discuss; it is not proof that a particular MCP host, version or permission configuration is enabled in your installation.

Back at the retailer, the useful Monday result is simple: the manager can verify 25 free approved bottles at her own store, with a timestamp, and cannot pull everyone else’s data. MCP made the request understandable to both programs. A tested access policy made that particular answer appropriate.

Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. The retailer, stock quantities and connection counts are teaching examples.