MCP in the enterprise: a field guide
How Coworkers read from and write back to the systems you already run.
An operations team rarely needs another place to manage its work. It needs the existing places to work together: the customer record, the support queue, the contract folder, the internal policy page.
An AI assistant becomes useful when it can retrieve the right evidence from those systems and help complete a bounded task. The challenge is deciding which records it may read, which actions it may propose, and who can authorize a change.
In this article, Coworkers is our shorthand for AI assistants working alongside people. It describes a working model, rather than a claim about a particular product’s available integrations.
The Model Context Protocol, or MCP, can supply a common interface between an assistant application and external capabilities. Enterprise readiness depends on the controls built around that interface.
What MCP standardizes#
MCP defines how an AI application exchanges context and invokes exposed capabilities. A host is the application coordinating the experience; its clients communicate with servers that expose capabilities. Servers can offer resources, such as contextual data; tools, such as executable functions; and prompts, such as reusable interaction templates. MCP does not determine how an application chooses its model or manages all the information it receives.
A server might wrap a ticketing API and expose tools to search tickets, fetch a record, or add an internal note. The underlying system still stores the record. The connector still needs to translate requests correctly and respect that system’s permissions.
This is useful standardization, with a practical limit: discovering a tool does not prove that the tool is appropriate for a particular business decision. A working connection is the beginning of integration design.
Separate connection, permission, and approval#
Enterprise discussions become clearer when four questions have separate answers:
| Layer | Question | Example |
|---|---|---|
| Protocol | How does the application request the capability? | Call an exposed ticket-update tool. |
| Authentication | Which identity is making the request? | An identified employee or dedicated service identity. |
| Authorization | What may that identity do? | Update internal notes for one support team. |
| Workflow approval | Is this specific change approved? | A supervisor approves a customer-facing commitment. |
MCP includes an authorization framework for HTTP transports, built around OAuth. Its specification treats the protected MCP server as a resource server and describes discovery and access-token handling. It does not supply your company’s approval policy for refunds, customer promises, or account changes.
Consider a hypothetical service team. An employee might have permission to edit a customer record while still needing a manager’s approval to promise a contract exception. Giving the assistant that employee’s access does not remove the approval requirement.
Define the business rule first, then enforce it in the execution path. The model can propose an action; the service performing it must check the caller, target record, allowed fields, and required approval.
Start with the smallest useful access#
For a first implementation, choose one operational question and the minimum evidence needed to answer it.
“Prepare a support handover for these open cases” is a clearer scope than “connect the assistant to support.” The former identifies a record set, an output, and a reviewable result.
Use a narrow set of tools with explicit inputs. Prefer a tool that adds an internal note to an authorized ticket over one that accepts arbitrary API requests. Limit accessible teams, projects, fields, and record types where the source system allows it. Preserve record-level permission checks; a broad service account needs explicit controls to prevent it from exposing more than the requesting employee may see.
Request only the permissions needed for the task. If a later workflow needs additional access, make that an explicit decision. Review the connector’s permissions alongside the records, actions, and users it is intended to serve.
Reading also carries risk. A read-only connection may expose confidential material, and summaries can copy it into a destination with wider access. Review both the source permissions and where the answer will appear.
Give reading and writing different paths#
A useful progression is retrieve, draft, approve, execute, verify.
In a hypothetical handover workflow, the Coworker retrieves selected tickets and relevant account context. It prepares a handover with links to the underlying records. A person reviews the draft. If an internal note should be added, the application shows the exact destination and proposed text before execution.
Implement read and write capabilities separately. A person should be able to use the research workflow without granting mutation access. Write tools should accept constrained fields and reject invalid values on the server.
For consequential changes, bind approval to the exact action, record, and content. If any of those change, reassess approval. Add protection against duplicate execution, such as an application-level operation identifier, and recheck relevant record state before committing.
After a write, return a durable record identifier and verify the resulting state. A timeout can leave the outcome uncertain; an automatic retry must not create a second note, order, or message. These are workflow engineering decisions, beyond basic protocol interoperability.
Treat retrieved content as untrusted evidence#
A legitimate ticket can contain hostile instructions. A document might tell an assistant to ignore its task, export another file, or send information to an outside address. Retrieving the text through an approved connector does not make those instructions authoritative.
This is indirect prompt injection: instructions arrive through material the assistant was supposed to read as evidence. Enforce permissions and validate tool arguments in the application and execution service. A warning in the prompt or a keyword filter cannot replace those checks.
Keep source content identifiable, preserve its provenance, and restrict the actions available while processing it. Validate outbound destinations and proposed parameters against the user’s task. Screen suspicious content as an additional layer, and test whether attacks can cause an unauthorized outcome.
Tool metadata needs scrutiny too. Treat a server’s description of its capabilities as a claim to verify. A “read-only” label should be checked against implementation behavior before the tool is made available to an assistant.
Choose deployment around the operating environment#
MCP supports stdio, for a client-launched process, and Streamable HTTP, for HTTP-based communication. For a centrally operated remote service, evaluate Streamable HTTP alongside identity integration, network policy, monitoring, and availability requirements.
Check the protocol versions your chosen host and server actually support. Transport behavior can differ between revisions, so test the pair you plan to deploy, including authentication, request handling, cancellation, and connection failures. A successful demonstration with a different version does not establish compatibility.
Review connector dependencies and credential handling. Validate that incoming access tokens are intended for the MCP server. Access to a downstream API needs credentials issued for that service, with the appropriate scope. Do not turn the connector into a route for forwarding arbitrary tokens between systems.
Test the boundaries before expanding#
Evaluate a complete workflow using representative cases, including:
- A user requesting a record outside their team.
- Retrieved text attempting to redirect the assistant’s next action.
- Missing, conflicting, or outdated source records.
- A revoked credential or upstream permission change.
- A write that succeeds upstream but returns a timeout.
- A proposed change whose content differs from the approved version.
Check the resulting system state and information disclosure, as well as the assistant’s response. A polite refusal is insufficient if a write already happened.
Define acceptance criteria with the process owner. Useful measures include factual support, correct record selection, unauthorized-action rejection, duplicate prevention, human correction effort, and completion time. Set thresholds before evaluating the pilot.
Keep an audit trail connecting the requesting identity, workflow, tool call, relevant record identifiers, approval decision, and execution outcome. Store only necessary content; exclude credentials and apply access and retention rules. The record should let an operator reconstruct what happened without exposing unrelated sensitive information.
Make one workflow dependable#
A sensible first release serves one team, one task, and a small set of systems. Begin with evidence retrieval and reviewed drafts. Introduce constrained writes after permissions, failure handling, approvals, and verification work together.
Assign an owner for each connector and each business workflow. Provide a way to disable writes quickly, and a human route for unresolved cases.
For an enterprise buyer, the decisive demonstration is a completed task with evidence, appropriate access, a reviewable change, and a trustworthy outcome. MCP gives teams a shared way to connect capabilities. Careful workflow design turns those connections into useful work.
